AddressFunctionScope was always returning the first address range of the
function (assuming it was the only one). This doesn't work for
RegisterContextUnwind (it's only caller), when the function doesn't
start at the lowest address because it throws off the 'how many bytes
"into" a function I am' computation. This patch replaces the result with
a call to (recently introduced)
SymbolContext::GetFunctionOrSymbolAddress.
CMake 4 no longer sets the `CMAKE_OSX_SYSROOT` variable by default. If
you've updated to CMake 4 on macOS (e.g. with brew) and try building
LLDB with CMake/ninja, this will yield an error when building
debugserver that clang is unable to run since it tries to compile files
that don't exist.
These files are supposed to be generated by the `mig` process. `mig`
needs the `CMAKE_OSX_SYSROOT` variable in order to work and without it,
it silently fails to generate the files that later on need to be
compiled.
This commit sets this SDK path for mig and will fatal error out of config
when building debugserver without having set CMAKE_OSX_SYSROOT.
Follow-up to #138892 fixing breakage on windows. Calling
ClearAllLoadedSections earlier is necessary to avoid throwing out the
work done by the windows process plugin.
The macos and sysv ABIs return functionally equivalent unwind plans, so
they can be implemented in the base AArch64 class. The only difference
between them was that the macos plan provided a "pc=lr" rule whereas the
sysv plan called SetReturnAddressRegister (which causes the unwind
machinery to act as if that rule was present). This difference was
enough to cause `CompareUnwindPlansForIdenticalInitialPCLocation` to
return a different value and break the (temporarily reverted)
TestUnwindFramelessFaulted test.
While merging the two functions, I couldn't stop myself from simplifying
them to use the generic register number schemes -- which exposed another
bug in CompareUnwindPlansForIdenticalInitialPCLocation, namely that it
was expecting all unwind plans to use the LLDB numbering scheme. This
patch fixes that as well.
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
- Add unit test for breakpoint types for SourceBreakpoint,
FunctionBreakpoint and DataBreakpoint.
- Rename DataBreakpointInfo to DataBreakpoint.
- Fix some mapOptions for optional fields.
std::string::find accepts anything that can be converted to
std::string_view starting in C++17. Since StringRef can be converted
to std::string_view, we do not need to create a temporary instance of
std::string here.
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).
Remove the `lldb-vscode` -> `lldb-dap` symlink in the `tools` directory.
I initially created the symlink when we renamed the tool to make
migration easier. I think enough time has passed that we don't need it
anymore.
My personal motivation is that the symlink causes every file in the
`lldb-dap` directory to show up twice (once under `lldb-dap` and once
under `lldb-vscode`) in Quick Open in VS Code.
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
This reverts commit
a0260a95ec,
reapplying
7c5f5f3ef8,
with a fix that makes *both*
pipe handles inheritable.
The original commit description was:
This is a follow-up to https://github.com/llvm/llvm-project/pull/126935,
which enables passing handles to a child
process on windows systems. Unlike on unix-like systems, the handles
need to be created with the "inheritable" flag because there's to way to
change the flag value after it has been created. This is why I don't
respect the child_process_inherit flag but rather always set the flag to
true. (My next step is to delete the flag entirely.)
This does mean that pipe may be created as inheritable even if its not
necessary, but I think this is offset by the fact that windows (unlike
unixes, which pass all ~O_CLOEXEC descriptors through execve and *all*
descriptors through fork) has a way to specify the precise set of
handles to pass to a specific child process.
If this turns out to be insufficient, instead of a constructor flag, I'd
rather go with creating a separate api to create an inheritable copy of
a handle (as typically, you only want to inherit one end of the pipe).
This function was replaced by GetInteger<T> which can handle both signed
and unsigned values. It currently had one caller in JSONUtils, which
this patch updates.
Split lldb-dap into a library (lldbDAP) and a tool (lldb-dap). The
motivation is being able to link parts of lldb-dap separately, for
example to support unit testing and fuzzing.
# 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.
