This reverts commit a89e01634fe2e6ce0b967ead24280b6693b523dc.
This is being reverted because it broke the test:
Unwind/trap_frame_sym_ctx.test
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input
CHECK: frame #2: {{.*}}`main
Currently, our unwinder assumes that the functions are continuous (or at
least, that there are no functions which are "in the middle" of other
functions). Neither of these assumptions is true for functions optimized
by tools like propeller and (probably) bolt.
While there are many things that go wrong for these functions, the
biggest damage is caused by the unwind plan caching code, which
currently takes the maximalist extent of the function and assumes that
the unwind plan we get for that is going to be valid for all code inside
that range. If a part of the function has been moved into a "cold"
section, then the range of the function can be many megabytes, meaning
that any function within that range will probably fail to unwind.
We end up with this maximalist range because the unwinder asks for the
Function object for its range. This is only one of the strategies for
determining the range, but it is the first one -- and also the most
incorrect one. The second choice would is asking the eh_frame section
for the range of the function, and this one returns something reasonable
here (the address range of the current function fragment) -- which it
does because each fragment gets its own eh_frame entry (it has to,
because they have to be continuous).
With this in mind, this patch moves the eh_frame (and debug_frame) to
the front of the queue. I think that preferring this range makes sense
because eh_frame is one of the unwind plans that we return, and some
others (augmented eh_frame) are based on it. In theory this could break
some functions, where the debug info and eh_frame disagree on the extent
of the function (and eh_frame is the one who's wrong), but I don't know
of any such scenarios.
…unction (#91321)"
This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `<same>` unwind rules
is recursive
- the test binary creates a very long chain of fp-less function frames
(it manages to fit about 22k frames before it blows its stack)
Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.
This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).
A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.
The original patch description follows:
A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.
To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = <same>`
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`<same>` rule.
- allows the `<same>` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).
The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
The stack validation heuristic is counter-productive in this case, as
the unaligned address is most likely the thing that caused the signal in
the first place.
This reverts commit fd1bd53ba5a06f344698a55578f6a5d79c457e30.
TestInterruptBacktrace was broken on AArch64/Windows as a result of this change.
See lldb-aarch64-windows buildbot here:
https://lab.llvm.org/buildbot/#/builders/219/builds/11261
This reverts commit b903badd73a2467fdd4e363231f2bf9b0704b546.
TestInterruptBacktrace was broken on AArch64/Windows as a result of this change.
see lldb-aarch64-windows buildbot here:
https://lab.llvm.org/buildbot/#/builders/219/builds/11261
Convert settings set EXC_BAD_INSTRUCTION to SIGILL so we get uniform
behavior (and can resume the inferior).
Fix a "omitting the parameter name in a function definition is a C23
extension" warning as a drive-by.
A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.
To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = <same>`
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`<same>` rule.
- allows the `<same>` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).
The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
Currently, lldb's unwinder ignores cfi_restore opcodes for registers
that are not set in the first row of the unwinding info. This prevents
unwinding of failed assertion in Chrome/v8 (https://github.com/v8/v8).
The attached test is an x64 copy of v8's function that failed to unwind
correctly (V8_Fatal).
This patch changes handling of cfi_restore to reset the location if
the first unwind table row does not map the restored register.
Differential Revision: https://reviews.llvm.org/D153043
clang supports option -fsplit-machine-functions and this test checks if the
backtraces are sane when functions are split.
With -fsplit-machine-functions, a function with profiles can get split into 2
parts, the original function containing hot code and a cold part as determined
by the profile info and the cold cutoff threshold.. The cold part gets the
".cold" suffix to disambiguate its symbol from the hot part and can be placed
arbitrarily in the address space.
This test checks if the back-trace looks correct when the cold part is executed.
Differential Revision: https://reviews.llvm.org/D90081
The test reorders the basic blocks to be dis-contiguous in the address space and checks if the back trace contains the right symbol.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D89179
Summary:
This fixes a bug in the logic for choosing the unwind plan. Based on the
comment in UnwindAssembly-x86, the intention was that a plan which
describes the function epilogue correctly does not need to be augmented
(and it should be used directly). However, the way this was implemented
(by returning false) meant that the higher level code
(FuncUnwinders::GetEHFrameAugmentedUnwindPlan) interpreted this as a
failure to produce _any_ plan and proceeded with other fallback options.
The fallback usually chosed for "asynchronous" plans was the
"instruction emulation" plan, which tended to fall over on certain
functions with multiple epilogues (that's a separate bug).
This patch simply changes the function to return true, which signals the
caller that the unmodified plan is ready to be used.
The attached test case demonstrates the case where we would previously
fall back to the instruction emulation plan, and unwind incorrectly --
the test asserts that the "augmented" eh_frame plan is used, and that
the unwind is correct.
Reviewers: jasonmolenda, jankratochvil
Subscribers: davide, echristo, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82378
lld in 2bfee35 started emitting relocations for some intra-section jumps
between global symbols. This shifted the code around a bit, invalidating
text expectations.
Change the symbols to local to keep the previous behavior.
D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on
Fedora 30 Linux x86_64.
[lldb] Add additional validation on return address in 'thread step-out'
https://reviews.llvm.org/D71372
One problem is the underscored `_nonstandard_stub` in the `.s` file but not in
the LLDB command:
(lldb) breakpoint set -n nonstandard_stub
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) process launch
Process 21919 exited with status = 0 (0x00000000)
Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64)
(lldb) thread step-out
error: invalid thread
(lldb) _
Another problem is that Fedora Linux has executable stack by default and all
programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the
underscore I was getting:
(lldb) thread step-out
Process 22294 exited with status = 0 (0x00000000)
(lldb) _
A different approach was tried as:
[lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable
https://reviews.llvm.org/D71789
Differential revision: https://reviews.llvm.org/D71784
Previously, if the current function had a nonstandard stack layout/ABI, and had a valid
data pointer in the location where the return address is usually located, data corruption
would occur when the breakpoint was written. This could lead to an incorrectly reported
crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts.
Differential Revision: https://reviews.llvm.org/D71372
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
