This is a revert of b1fcc1840c312472cb9ccb8c4e5e02ca13b31113.
These tests weren't working on Ubuntu 22.04 or Fedora 37-40. I'm not
sure exactly why, but it seems like they may be incompatible with
libstdc++. Also, despite the fact that the tests were using the system
libstdc++, the tests were only run when libcxx was enabled.
I tested this with a RelWithDebInfo build and the tests passed.
Fixes#106475
(cherry picked from commit adf44d5c3ea03569f019740e1140c3205810b3fa)
This fixes a regression caused by delayed type definition searching
(#96755 and friends): If we end up adding a member (e.g. a typedef) to a
type that we've already attempted to complete (and failed), the
resulting AST would end up inconsistent (we would start to "forcibly"
complete it, but never finish it), and importing it into an expression
AST would crash.
This patch fixes this by detecting the situation and finishing the
definition as well.
(cherry picked from commit 57cd1000c9c93fd0e64352cfbc9fbbe5b8a8fcef)
This class is technically not usable in its current state. When you use
it in a simple C++ project, your compiler will complain about an
incomplete definition of SaveCoreOptions. Normally this isn't a problem,
other classes in the SBAPI do this. The difference is that
SBSaveCoreOptions has a default destructor in the header, so the
compiler will attempt to generate the code for the destructor with an
incomplete definition of the impl type.
All methods for every class, including constructors and destructors,
must have a separate implementation not in a header.
(cherry picked from commit 101cf540e698529d3dd899d00111bcb654a3c12b)
Similar to #97796, fix the type of the `native_thread` parameter for the
arm, mips64 and powerpc variants of `NativeRegisterContextFreeBSD_*`.
Otherwise, this leads to compile errors similar to:
```
lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_powerpc.cpp:85:39: error: out-of-line definition of 'NativeRegisterContextFreeBSD_powerpc' does not match any declaration in 'lldb_private::process_freebsd::NativeRegisterContextFreeBSD_powerpc'
85 | NativeRegisterContextFreeBSD_powerpc::NativeRegisterContextFreeBSD_powerpc(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
(cherry picked from commit 7088a5ed880f29129ec844c66068e8cb61ca98bf)
On linux, the start address doesn't necessarily have a symbol attached
to it.
This is why this patch replaces `DynamicLoader::GetStartSymbol` with
`DynamicLoader::GetStartAddress` instead to make it more generic.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
HostProcessWindows::Terminate() correctly uses m_process which type is
process_t (HANDLE) to call ::TerminateProcess(). But Host::Kill() uses a
cast from pid, which is wrong.
This patch fixes#51793
This reverts commit 05f0e86cc895181b3d2210458c78938f83353002.
The debuginfo dexter tests are failing, probably because the way
stepping over breakpoints has changed with my patches. And there
are two API tests fails on the ubuntu-arm (32-bit) bot. I'll need
to investigate both of these, neither has an obvious failure reason.
lldb today has two rules: When a thread stops at a BreakpointSite, we
set the thread's StopReason to be "breakpoint hit" (regardless if we've
actually hit the breakpoint, or if we've merely stopped *at* the
breakpoint instruction/point and haven't tripped it yet). And second,
when resuming a process, any thread sitting at a BreakpointSite is
silently stepped over the BreakpointSite -- because we've already
flagged the breakpoint hit when we stopped there originally.
In this patch, I change lldb to only set a thread's stop reason to
breakpoint-hit when we've actually executed the instruction/triggered
the breakpoint. When we resume, we only silently step past a
BreakpointSite that we've registered as hit. We preserve this state
across inferior function calls that the user may do while stopped, etc.
Also, when a user adds a new breakpoint at $pc while stopped, or changes
$pc to be the address of a BreakpointSite, we will silently step past
that breakpoint when the process resumes. This is purely a UX call, I
don't think there's any person who wants to set a breakpoint at $pc and
then hit it immediately on resuming.
One non-intuitive UX from this change, but I'm convinced it is
necessary: If you're stopped at a BreakpointSite that has not yet
executed, you `stepi`, you will hit the breakpoint and the pc will not
yet advance. This thread has not completed its stepi, and the thread
plan is still on the stack. If you then `continue` the thread, lldb will
now stop and say, "instruction step completed", one instruction past the
BreakpointSite. You can continue a second time to resume execution. I
discussed this with Jim, and trying to paper over this behavior will
lead to more complicated scenarios behaving non-intuitively. And mostly
it's the testsuite that was trying to instruction step past a breakpoint
and getting thrown off -- and I changed those tests to expect the new
behavior.
The bugs driving this change are all from lldb dropping the real stop
reason for a thread and setting it to breakpoint-hit when that was not
the case. Jim hit one where we have an aarch64 watchpoint that triggers
one instruction before a BreakpointSite. On this arch we are notified of
the watchpoint hit after the instruction has been unrolled -- we disable
the watchpoint, instruction step, re-enable the watchpoint and collect
the new value. But now we're on a BreakpointSite so the watchpoint-hit
stop reason is lost.
Another was reported by ZequanWu in
https://discourse.llvm.org/t/lldb-unable-to-break-at-start/78282 we
attach to/launch a process with the pc at a BreakpointSite and
misbehave. Caroline Tice mentioned it is also a problem they've had with
putting a breakpoint on _dl_debug_state.
The change to each Process plugin that does execution control is that
1. If we've stopped at a BreakpointSite that has not been executed yet,
we will call Thread::SetThreadStoppedAtUnexecutedBP(pc) to record
that. When the thread resumes, if the pc is still at the same site, we
will continue, hit the breakpoint, and stop again.
2. When we've actually hit a breakpoint (enabled for this thread or not),
the Process plugin should call Thread::SetThreadHitBreakpointSite().
When we go to resume the thread, we will push a step-over-breakpoint
ThreadPlan before resuming.
The biggest set of changes is to StopInfoMachException where we
translate a Mach Exception into a stop reason. The Mach exception codes
differ in a few places depending on the target (unambiguously), and I
didn't want to duplicate the new code for each target so I've tested
what mach exceptions we get for each action on each target, and
reorganized StopInfoMachException::CreateStopReasonWithMachException to
document these possible values, and handle them without specializing
based on the target arch.
rdar://123942164
In #98403 some of the tests were transitioned to the new
`SBProcess::SaveCore(SBSaveCoreOptions)` API, but were not detected in
testing. This patch addresses that.
This patch introduces a new method to the dynamic loader plugin, to
fetch its `start` symbol.
This can be useful to resolve the `start` symbol address for instance.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
.sbss section was recognized as eSectionTypeOther, but has to be
eSectionTypeZeroFill.
Fixed tests for RISCV target:
TestClassLoadingViaMemberTypedef.TestCase
TestClassTemplateNonTypeParameterPack.TestCaseClassTemplateNonTypeParameterPack
TestThreadSelectionBug.TestThreadSelectionBug
lldbsuite.test.lldbtest.TestOffsetof
lldbsuite.test.lldbtest.TestOffsetofCpp
TestTargetDumpTypeSystem.TestCase
TestCPP11EnumTypes.CPP11EnumTypesTestCase
TestCppIsTypeComplete.TestCase
TestExprCrash.ExprCrashTestCase
TestDebugIndexCache.DebugIndexCacheTestcase
In MinGW make, the `%windir%` variable has a lowercase name `$(windir)`
when launched from cmd.exe, and `$(WINDIR)` name when launched from
MSYS2, since MSYS2 represents standard Windows environment variables
names in upper case.
This commit makes Makefile.rules consider both run variants.
This PR adds `SBSaveCoreOptions`, which is a container class for options
when LLDB is taking coredumps. For this first iteration this container
just keeps parity with the extant API of `file, style, plugin`. In the
future this options object can be extended to allow users to take a
subset of their core dumps.
Remove commands for OS/HOST_OS detection from Makefile.rules to simplify
it, since logic for these variables has been implemented in
`lldb/packages/Python/lldbsuite/test/lldbplatformutil.py`
(7021e44b2f0e11717c0d82456bad0fed4a0b48f9).
TestPlatformLaunchGDBServer.py runs `ldb-server` w/o parameters
`--min-gdbserver-port`, `--max-gdbserver-port` or `--gdbserver-port`. So
`gdbserver_portmap` is empty and
`gdbserver_portmap.GetNextAvailablePort()` will return 0. Do not call
`portmap_for_child.AllowPort(0)` in this case. Otherwise
`portmap_for_child.GetNextAvailablePort()` will allocate and never free
the port 0 and next call `portmap_for_child.GetNextAvailablePort()` will
fail.
Added few asserts in `GDBRemoteCommunicationServerPlatform::PortMap` to
avoid such issue in the future.
This patch fixes a bug added in #88845. The behaviour is very close to
#97537 w/o parameters `--min-gdbserver-port`, `--max-gdbserver-port` and
`--gdbserver-port`.
When doing firmware/kernel debugging, it is frequent that binaries and
debug info need to be retrieved / downloaded, and the lack of progress
reports made for a poor experience, with lldb seemingly hung while
downloading things over the network. This PR adds progress reports to
the critical sites for these use cases.
CreateFunctionEntryUnwindPlan RISCV ABI function fix needed to receive a
valid backtrace at the start of functions.
Fixed tests for RISCV target:
TestNumThreads.NumberOfThreadsTestCase
TestCPPExceptionBreakpoints.CPPBreakpointTestCase
TestStepThroughTrampoline.StepThroughTrampoline
TestOSPluginStepping.TestOSPluginStepping
TestSteppingOutWithArtificialFrames.TestArtificialFrameThreadStepOut1
TestStepAvoidsRegexp.StepAvoidsRegexTestCase
TestInlineStepping.TestInlineStepping
TestStepOverBreakpoint.StepOverBreakpointsTestCase
TestStepOverBreakpoint.StepOverBreakpointsTestCase
TestSteppingOutWithArtificialFrames.TestArtificialFrameThreadStepOut1
TestTailCallFrameSBAPI.TestTailCallFrameSBAPI
TestThreadPlanUserBreakpoint.ThreadPlanUserBreakpointsTestCase
Currently, if we execute 'process load' with remote debugging, it uses
the host's path delimiter to look up files on a target machine. If we
run remote debugging of Linux target on Windows and execute "process
load C:\foo\a.so", lldb-server tries to load \foo\a.so instead of
/foo/a.so on the remote.
It affects several API tests.
This commit fixes that error. Also, it contains minor fixes for
TestLoadUnload.py for testing on Windows host and Linux target.
The strings this test is using seem to consistently fail to match
against the expected values when built & run targeting Windows amd64.
This PR updates them to the expected values.
To fix the test and avoid over-specifying for a specific platform, use
`assertIn(<target-substring>,...)` to see if we've got the correct
target label instead of comparing the demangler output for an exact
string match.
---------
Co-authored-by: kendal <kendal@thebrowser.company>
This patch adds an interface GetLastInstrSize to get information about
the size of last tried to be decoded instruction and uses it to set
software breakpoint if the memory can be decoded as instruction.
RISC-V architecture instruction format specifies the length of
instruction in first bits, so we can set a breakpoint for these cases.
This is needed as RISCV have a lot of extensions, that are not supported
by `EmulateInstructionRISCV`.
This is motivated by the upcoming refactor of libc++'s
`__compressed_pair` in https://github.com/llvm/llvm-project/pull/76756
As this will require changes to numerous LLDB libc++ data-formatters
(see early draft https://github.com/llvm/llvm-project/pull/96538), it
would be nice to have a test-suite that will actually exercise both the
old and new layout. We have a matrix bot that tests old versions of
Clang (but currently those only date back to Clang-15). Having them in
the test-suite will give us quicker signal on what broke.
We have an existing test that exercises various layouts of `std::string`
over time in `TestDataFormatterLibcxxStringSimulator.py`, but that's the
only STL type we have it for. This patch proposes a new
`libcxx-simulators` directory which will take the same approach for all
the STL types that we can feasibly support in this way (as @labath
points out, for some types this might just not be possible due to their
implementation complexity). Nonetheless, it'd be great to have a record
of how the layout of libc++ types changed over time.
Some related discussion:
*
https://github.com/llvm/llvm-project/pull/97568#issuecomment-2213426804
The help output incorrectly states that this command takes a shared
library name (<shlib-name>) while really it takes a path to a symbol
file.
rdar://131777043
This patch adds a frame recognizer for Clang's
`__builtin_verbose_trap`, which behaves like a
`__builtin_trap`, but emits a failure-reason string into debug-info in
order for debuggers to display
it to a user.
The frame recognizer triggers when we encounter
a frame with a function name that begins with
`__clang_trap_msg`, which is the magic prefix
Clang emits into debug-info for verbose traps.
Once such frame is encountered we display the
frame function name as the `Stop Reason` and display that frame to the
user.
Example output:
```
(lldb) run
warning: a.out was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 35942 launched: 'a.out' (arm64)
Process 35942 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = Misc.: Function is not implemented
frame #1: 0x0000000100003fa4 a.out`main [inlined] Dummy::func(this=<unavailable>) at verbose_trap.cpp:3:5 [opt]
1 struct Dummy {
2 void func() {
-> 3 __builtin_verbose_trap("Misc.", "Function is not implemented");
4 }
5 };
6
7 int main() {
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = Misc.: Function is not implemented
frame #0: 0x0000000100003fa4 a.out`main [inlined] __clang_trap_msg$Misc.$Function is not implemented$ at verbose_trap.cpp:0 [opt]
* frame #1: 0x0000000100003fa4 a.out`main [inlined] Dummy::func(this=<unavailable>) at verbose_trap.cpp:3:5 [opt]
frame #2: 0x0000000100003fa4 a.out`main at verbose_trap.cpp:8:13 [opt]
frame #3: 0x0000000189d518b4 dyld`start + 1988
```
This reverts commit 2fa1220a37a3f55b76a29803d8333b3a3937d53a.
This reverts commit b9496a74eb4029629ca2e440c5441614e766f773.
The patch #98344 causes a crash in LLDB when parsing some files like `numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link if you want to troubleshoot yourself).
The assert that is hit is the following:
```
llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: std::pair<unsigned int, std::map<long unsigned int, lldb_private::AddressClass> > ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed.
[383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] Crashpad isn't enabled
```
This object file doesn't have apparently a strings table but LLDB still tries to process it due to the code that is being reverted.
Frequently, while troubleshooting user's debugging issues in VScode, we
would like to know lldb version so that we can confirm if certain
patch/feature is in or not.
This PR adds version string into `initialize` response so that telemetry
can track it.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
This patch hoists the `SymbolLocation` struct from the
`AssertFrameRecognizer` source file, since it's pretty generic and could
be reused for other purposes.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
A new file was added to the python_api/events test, but I forgot to
git add it before making the PR. The commit was:
44d9692e6a657ec46e98e4912ac56417da67cfee
This fixes a bug where Process events were being delivered to secondary
listeners when the Private state thread listener was processing the
event. That meant the secondary listener could get an event before the
Primary listener did. That in turn meant the state when the secondary
listener got the event wasn't right yet. Plus it meant that the
secondary listener saw more events than the primary (not all events get
forwarded from the private to the public Process listener.)
This bug became much more evident when we had a stop hook that did some
work, since that delays the Primary listener event delivery. So I also
added a stop-hook to the test, and put a little delay in as well.
Seemingly, #96256 removed the only call to
Platform::GetCachedExecutable, which broke the resolution of executable
modules in the remote debugging mode
(https://github.com/llvm/llvm-project/issues/97410).
This commit fixes that.
In RegisterContextUnwind::SavedLocationForRegister we have special logic
for retrieving the Return Address register when it has the caller's
return address in it. An example would be the lr register on AArch64.
This register is never retrieved from a newer stack frame because it is
necessarly overwritten by a normal ABI function call. We allow frame 0
to provide its lr value to get the caller's return address, if it has
not been overwritten/saved to stack yet.
When a function is interrupted asynchronously by a POSIX signal
(sigtramp), or a fault handler more generally, the sigtramp/fault
handler has the entire register context available. In this situation, if
the fault handler is frame 0, the function that was async interrupted is
frame 1 and frame 2's return address may still be stored in lr. We need
to get the lr value for frame 1 from the fault handler in frame 0, to
get the return address for frame 2.
Without this fix, a frameless function that faults in a firmware
environment (that's where we've seen this issue most commonly) hasn't
spilled lr to stack, so we need to retrieve it from the fault handler's
full-register-context to find the caller of the frameless function that
faulted.
It's an unsurprising fix, all of the work was finding exactly where in
RegisterContextUnwind we were only allowing RA register use for frame 0,
when it should have been frame 0 or above a fault handler function.
rdar://127518945
This was found during testing of llvm snapshots for Fedora.
This test was looking for an exact string match of the path calculated
by starting with lib/liblldb and with bin/lldb. However when
CLANG_RESOURCE_DIR is set to something e.g. "../lib/clang/19", the way
the initial path is handled is different.
Instead of taking the parent of the parent of the binary, that is
foo/bin/lldb/ -> foo/, it uses the parent of the binary and appends
CLANG_RESOURCE_DIR to that. As CLANG_RESOURCE_DIR is defined as being a
path relative to the parent dir's of the clang binary.
This means that if you start with foo/lib/lidblldb the resulting path is
lib/../lib/clang/19, but if you start with bin/lldb the result is
bin/../lib/clang/19.
I don't want to change the starting path of
DefaultComputeClangResourceDirectory (which is bin/lldb) as I suspect
that's chosen instead of liblldb for good reason.
So the way to make this test work is to check not for exact path matches
but that the "real" (".." resolved) version of the paths are the same.
That way foo/bin/../lib and foo/lib/../lib will be the same.
This test sets a breakpoint on malloc, as a way to stop early in
dyld's setting up code, before the system libraries are initialized
so we can confirm that we don't fetch the Objective-C class table
before it's initialized.
In macOS 15 (macOS Sonoma), dyld doesn't call malloc any longer,
so this heuristic/trick isn't working. It does call other things
called *alloc though, so I'm changing this to use a regex breakpoint
on that, to keep the test working.
PT_LOAD and PT_TLS segments are top level sections in the ObjectFileELF
section list. The two segments can often have the same program header
p_vaddr and p_paddr values and this can cause section load list issues
in LLDB if we load the PT_TLS segments. What happens is the
SectionLoadList::m_addr_to_sect, when a library is loaded, will first
map one of the sections named "PT_LOAD[0]" with the load address that
matches the p_vaddr entry from the program header. Then the "PT_TLS[0]"
would come along and try to load this section at the same address. This
would cause the "PT_LOAD[0]" section to be unloaded as the
SectionLoadList::m_addr_to_sect would replace the value for the matching
p_vaddr with the last section to be seen. The sizes of the PT_TLS and
PT_LOAD that have the same p_vaddr value don't need to have the same
byte size, so this could cause lookups to fail for an addresses in the
"PT_LOAD[0]" section or any of its children if the offset is greater
than the offset size of the PT_TLS segment. It could also cause us to
incorrectly attribute addresses from the "PT_LOAD[0]" to the "PT_TLS[0]"
segment when doing lookups for offset that are less than the size of the
PT_TLS segment.
This fix stops us from loading PT_TLS segments in the section load lists
and will prevent the bugs that resulted from this. No addresses the the
DWARF refer to TLS data with a "file address" in any way. They all have
TLS DWARF location expressions to locate these variables. We also don't
have any support for having actual thread specific sections and having
those sections resolve to something different for each thread, so there
currently is no point in loading thread specific sections. Both the
ObjectFileMachO and ObjectFileCOFF both ignore thread specific sections
at the moment, so this brings the ObjectFileELF to parity with those
plug-ins.
I added a test into an existing test to verify that things work as
expected.
Prior to this fix with a real binary, the output of "target dump
section-load-list" would look like this for the old LLDB:
```
// (lldb) target dump section-load-list
// addr = 0x0000000000000000, section = 0x55d46ab8c510: 0xfffffffffffffffd container [0x0000000000000000-0x0000000000000628) r-- 0x00000000 0x00000628 0x00000000 a.out.PT_LOAD[0]
// addr = 0x0000000000001000, section = 0x55d46ab8b0c0: 0xfffffffffffffffc container [0x0000000000001000-0x0000000000001185) r-x 0x00001000 0x00000185 0x00000000 a.out.PT_LOAD[1]
// addr = 0x0000000000002000, section = 0x55d46ac040f0: 0xfffffffffffffffb container [0x0000000000002000-0x00000000000020cc) r-- 0x00002000 0x000000cc 0x00000000 a.out.PT_LOAD[2]
// addr = 0x0000000000003db0, section = 0x55d46ab7cef0: 0xfffffffffffffff6 container [0x0000000000003db0-0x0000000000003db4) r-- 0x00002db0 0x00000000 0x00000000 a.out.PT_TLS[0]
```
And this for the fixed LLDB:
```
// (lldb) target dump section-load-list
// addr = 0x0000000000000000, section = 0x105f0a9a8: 0xfffffffffffffffd container [0x0000000000000000-0x0000000000000628) r-- 0x00000000 0x00000628 0x00000000 a.out.PT_LOAD[0]
// addr = 0x0000000000001000, section = 0x105f0adb8: 0xfffffffffffffffc container [0x0000000000001000-0x0000000000001185) r-x 0x00001000 0x00000185 0x00000000 a.out.PT_LOAD[1]
// addr = 0x0000000000002000, section = 0x105f0af48: 0xfffffffffffffffb container [0x0000000000002000-0x00000000000020cc) r-- 0x00002000 0x000000cc 0x00000000 a.out.PT_LOAD[2]
// addr = 0x0000000000003db0, section = 0x105f0b078: 0xfffffffffffffffa container [0x0000000000003db0-0x0000000000004028) rw- 0x00002db0 0x00000274 0x00000000 a.out.PT_LOAD[3]
```
We can see that previously the "PT_LOAD[3]" segment would be removed
from the section load list, and after the fix it remains and there is on
PT_TLS in the loaded sections.
ThreadList uses the Process mutex to guard its state. This means its not
possible to safely modify its process member, as the member is required
to lock the mutex.
Fortunately for us, we never actually need to change the process member
(we always just juggle different kinds of thread lists belonging to the
same process).
This patch replaces the process member assignment (which is technically
a race even when it assigns the same value) with an assertion.
Since all this means that the class can never change its process member
value (and it also must be non-null at all times), I've also changed the
member type to a reference.
Previously this took a reference to a map and returned a bool to say
whether it succeeded. We can return a StringMap instead, as all callers
but 1 simply iterated the map if the bool was true, and passed in empty
maps as the starting point.
lldb's lit-cpuid did specifically check whether the call failed, but due
to the way the x86 routines work this works out the same as checking if
the returned map is empty.
