Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).
This used to work until #109477, which enabled the dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.
Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.
This fixes TestDynamicValue.py:test_from_core_file on darwin.
To improve logging this adjusts two properties of the existing tests:
* Forwards stderr from lldb-dap to the process in case errors are
reported to stderr.
* Adjusts `DebugAdapterServer.terminate` to close stdin and wait for the
process to exit instead of sending SIGTERM. Additionally, if we end up
with a non-zero exit status we now raise an error to note the unexpected
exit status.
With these changes, I did find one test case in
`TestDAP_console.test_diagnositcs` that was not waiting to ensure the
expected event had arrived by the time it performed an assert.
I thought I could call $(CPP) to preprocess the assembly
file, but the aarch64-ubuntu bot runs this as clang -E and
it issues a warning and no output file, apparently,
build/bin/clang -E -o interrupt-and-trap-funcs.s /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/unwind/frameless-faulted/interrupt-and-trap-funcs.s
clang: warning: /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/unwind/frameless-faulted/interrupt-and-trap-funcs.s: 'assembler' input unused [-Wunused-command-line-argument]
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang -g -O0 -c -o interrupt-and-trap-funcs.o interrupt-and-trap-funcs.s
clang: error: no such file or directory: 'interrupt-and-trap-funcs.s'
clang: error: no input files
When an intra-module jump doesn't fit in the immediate branch slot, the
Darwin linker inserts "branch island" symbols, and emits code to jump
from branch island to branch island till it makes it to the actual
function.
The previous submissions failed because in that environment the linker
was putting the `foo.island` symbol at the same address as the `padding`
symbol we we emitting to make our faked-up large binary. This submission
jams a byte after the padding symbol so that the other symbols can't
overlap it.
test_common is force-included into every compilation, which causes
problems when we're compiling assembly code, as we were in #138805.
This avoids that as we can include the header only when it's needed.
Here we were initializing & locking a shared_mutex in a thread, while
releasing it in the parent which may/often turned out to be a different
thread (shared_mutex::unlock_shared is undefined behavior if called from
a thread that doesn't hold the lock).
Switch to counter to more simply keep track of number of readers and
simply lock/unlock rather than utilizing reader mutex to verify last
freed (and so requiring this matching thread init/destroy behavior).
Re-landing this patch with small tweaks to address CI bot failures
as it was run on many different configurations. I think the test
may run on aarch64 Linux systems now.
When a frameless function faults or is interrupted asynchronously, the
UnwindPlan MAY have no register location rule for the return address
register (lr on arm64); the value is simply live in the lr register when
it was interrupted, and the frame below this on the stack -- e.g.
sigtramp on a Unix system -- has the full register context, including
that register.
RegisterContextUnwind::SavedLocationForRegister, when asked to find the
caller's pc value, will first see if there is a pc register location. If
there isn't, on a Return Address Register architecture like
arm/mips/riscv, we rewrite the register request from "pc" to "RA
register", and search for a location.
On frame 0 (the live frame) and an interrupted frame, the UnwindPlan may
have no register location rule for the RA Reg, that is valid. A
frameless function that never calls another may simply keep the return
address in the live register the whole way. Our instruction emulation
unwind plans explicitly add a rule (see Pavel's May 2024 change
https://github.com/llvm/llvm-project/pull/91321 ), but an UnwindPlan
sourced from debug_frame may not.
I've got a case where this exactly happens - clang debug_frame for arm64
where there is no register location for the lr in a frameless function.
There is a fault in the middle of this frameless function and we only
get the lr value from the fault handler below this frame if lr has a
register location of `IsSame`, in line with Pavel's 2024 change.
Similar to how we see a request of the RA Reg from frame 0 after failing
to find an unwind location for the pc register, the same style of
special casing is needed when this is a function that was interrupted.
Without this change, we can find the pc of the frame that was executing
when it was interrupted, but we need $lr to find its caller, and we
don't descend down to the trap handler to get that value, truncating the
stack.
rdar://145614545
# PR Summary
Small PR - Several test functions for `term-width/height` completions
had identical names, causing silent overriding. This gives them distinct
_width/_height suffixes to ensure all tests run.
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
This test is failing on the LLDB Incremental bot (arm64), which is
running an older set of tools (Xcode 15.2) and OS (macOS 14.1) and
the CFI directives must not be emitted correctly by either the tools
or the OS. I will need to reproduce how this is compiling on that
older setup and see what the issue is. Reverting for now so the
bots are not blocked.
This reverts commit e897cb139ee6ef5c145fed5394c4d96baa658e6b.
Failed at compile time lldb-aarch64-ubuntu bot.
It did clang -E -o interrupt-and-trap-funcs.s interrupt-and-trap-funcs.c
and that added a bunch of standard C header typedefs to
the output .s file which then turn into compile errors
when it tries to compile the .s file as assembly. Never saw
that behavior in my testing on an ubuntu 24.04 system.
It would have been nice to have the test run on Linux as well
as Darwin, but it's not essential.
When a frameless function faults or is interrupted asynchronously, the
UnwindPlan MAY have no register location rule for the return address
register (lr on arm64); the value is simply live in the lr register when
it was interrupted, and the frame below this on the stack -- e.g.
sigtramp on a Unix system -- has the full register context, including
that register.
RegisterContextUnwind::SavedLocationForRegister, when asked to find the
caller's pc value, will first see if there is a pc register location. If
there isn't, on a Return Address Register architecture like
arm/mips/riscv, we rewrite the register request from "pc" to "RA
register", and search for a location.
On frame 0 (the live frame) and an interrupted frame, the UnwindPlan may
have no register location rule for the RA Reg, that is valid. A
frameless function that never calls another may simply keep the return
address in the live register the whole way. Our instruction emulation
unwind plans explicitly add a rule (see Pavel's May 2024 change
https://github.com/llvm/llvm-project/pull/91321 ), but an UnwindPlan
sourced from debug_frame may not.
I've got a case where this exactly happens - clang debug_frame for arm64
where there is no register location for the lr in a frameless function.
There is a fault in the middle of this frameless function and we only
get the lr value from the fault handler below this frame if lr has a
register location of `IsSame`, in line with Pavel's 2024 change.
Similar to how we see a request of the RA Reg from frame 0 after failing
to find an unwind location for the pc register, the same style of
special casing is needed when this is a function that was interrupted.
Without this change, we can find the pc of the frame that was executing
when it was interrupted, but we need $lr to find its caller, and we
don't descend down to the trap handler to get that value, truncating the
stack.
rdar://145614545
My current internal work requires some sensitivity to IO usage. I had a
work around to calculate the expected size of a Minidump, but I've added
this PR so an automated system could look at the expected size of an
LLDB generated Minidump and then choose if it has the space or wants to
generate it.
There are some prerequisites to calculating the correct size, so I have
the API take a reference for an SBError, I originally tried to return an
SBError and instead take a uint64_t reference, but this made the API
very difficult to use in python.
Added a test case as well.
These are currently failing on Windows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/8556
```
********************
Unresolved Tests (1):
lldb-api :: tools/lldb-dap/memory/TestDAP_memory.py
********************
Failed Tests (1):
lldb-api :: tools/lldb-dap/variables/TestDAP_variables.py
```
This test is failing because when we step to what is the branch island
address and ask for its symbol, we can't resolve the symbol, and just
call it the last padding symbol plus a bajillion.
That has nothing to do with the changes in this patch, but I'll revert
this and keep trying to figure out why symbol reading on this bot is
wrong.
When we get to the branch island, we don't see the symbol for
it.
The only other thing I can think of that would be a dsymutil bug?
Let's try this just with dwarf, and then I'll have to revert all this
and see if I can reproduce this locally somehow.
This patch allows lldb to step in across "branch islands" which is the
Darwin linker's way of dealing with immediate branches to targets that
are too far away for the immediate slot to make the jump.
I submitted this a couple days ago and it failed on the arm64 bot. I was
able to match the bot OS and Tool versions (they are a bit old at this
point) and ran the test there but sadly it succeeded. The x86_64 bot
also failed but that was my bad, I did @skipUnlessDarwin when I should
have done @skipUnlessAppleSilicon.
So this resubmission is with the proper decoration for the test, and
with a bunch of debug output printed in case of failure. With any luck,
if this resubmission fails again I'll be able to see what's going on.
This updates the `attach` request to the typed
`RequestHandler<protocol::AttachRequestArguments,
protocol::AttachResponse>`.
Added a few more overlapping configurations to
`lldb_dap::protocol::Configuration` that are shared between launching
and attaching.
There may be some additional code we could clean-up that is no longer
referenced now that this has migrated to use well defined types.
Change the default statusline format to print "no target" when lldb is
launched without a target. Currently, the statusline is empty, which
looks rather odd.
Since https://github.com/llvm/llvm-project/pull/138981 / aeeb9a3c09
were landed and tests re-enabled, these tests have been failing
on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/8523
********************
Unresolved Tests (1):
lldb-api :: tools/lldb-dap/send-event/TestDAP_sendEvent.py
********************
Failed Tests (2):
lldb-api :: tools/lldb-dap/launch/TestDAP_launch.py
lldb-api :: tools/lldb-dap/stackTrace/TestDAP_stackTrace.py
Re-enable the lldb-dap tests. We've spent the last week improving the
reliability of the test suite and the tests now pass reliably on macOS
and Linux at desk. Let's see how things fare on the bots.
When handling anonymous structs, GetIndexOfChildMemberWithName needs to
add the number of non-empty base classes to the child index, to get the
actual correct index. It was not doing so. This fixes that.
This PR changes how we treat the launch sequence in lldb-dap.
- Send the initialized event after we finish handling the initialize
request, rather than after we finish attaching or launching.
- Delay handling the launch and attach request until we have handled
the configurationDone request. The latter is now largely a NO-OP and
only exists to signal lldb-dap that it can handle the launch and
attach requests.
- Delay handling the initial threads requests until we have handled
the launch or attach request.
- Make all attaching and launching synchronous, including when we have
attach or launch commands. This removes the need to synchronize
between the request and event thread.
Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125
We're reading from the object's vtable to determine the pointer to the
full object. The vtable is normally in the "rodata" section of the
executable, which is often not included in the core file because it's
not supposed to change and the debugger can extrapolate its contents
from the executable file. We weren't doing that.
This patch changes the read operation to use the target class (which
falls back onto the executable module as expected) and adds the missing
ReadSignedIntegerFromMemory API. The fix is tested by creating a core
(minidump) file which deliberately omits the vtable pointer.
Make stopOnAttach=False the default again and explicitly pass
stopOnAttach=True where the tests relies on that. I changed the default
in the launch sequence PR (#138219) because that was implicitly the
assumption (the tests never send the configurationDone request).
This PR changes how we treat the launch sequence in lldb-dap.
- Send the initialized event after we finish handling the initialize
request, rather than after we finish attaching or launching.
- Delay handling the launch and attach request until we have handled
the configurationDone request. The latter is now largely a NO-OP and
only exists to signal lldb-dap that it can handle the launch and
attach requests.
- Delay handling the initial threads requests until we have handled
the launch or attach request.
- Make all attaching and launching synchronous, including when we have
attach or launch commands. This removes the need to synchronize
between the request and event thread.
Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125
```cpp
// The "id" is the unique integer ID that is unique within the enclosing
// variablesReference. It is optionally added to any "interface
Variable"
// objects to uniquely identify a variable within an enclosing
// variablesReference. It helps to disambiguate between two variables
that
// have the same name within the same scope since the "setVariables"
request
// only specifies the variable reference of the enclosing
scope/variable, and
// the name of the variable. We could have two shadowed variables with
the
// same name in "Locals" or "Globals". In our case the "id" absolute
index
// of the variable within the dap.variables list.
const auto id_value =
GetInteger<uint64_t>(arguments, "id").value_or(UINT64_MAX);
if (id_value != UINT64_MAX) {
```
I dropped this part because. variables that have the same name has a ` @path` suffix on both of them.
and the setVariableArguments does not have a field called `id`.
The newly added test test_from_forward_decl in TestDynamicValue.py
by PR #137974 is failing on Windows due to issues with dynamic type
resolution. This is a known issue tracked in PR24663.
LLDB Windows on Arm Buildbot Failure:
https://lab.llvm.org/buildbot/#/builders/141/builds/8391
This change marks the test as XFAIL on Windows using the consistent
with how similar tests in the same file are handled.
This reverts commit 1ba89ad2c6e405bd5ac0c44e2ee5aa5504c7aba1.
This was failing on the Green Dragon bot, which has an older OS than
have on hand, so I'll have to dig up one and see why it's failing there.
