Current state in scripted process expects [all the
modules](912b154f3a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (L498))
passed into "get_loaded_images" to load successfully else none of them
load. Even if a module loads fine, [but has already been
appended](912b154f3a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (L495))
it still fails. This is restrictive and does not help our usecase.
**Usecase**: We have a parent scripted process using coredump +
tombstone.
1) Scripted process uses child elf-core process to read memory dump
2) Uses tombstones to pass thread names and modules.
We do not know whether the modules will be successfully downloaded
before creating the scripted process. We use [python module
callbacks](a57e58dbfa/lldb/source/Target/Platform.cpp (L1593))
to download a module from symbol server at LLDB load time when the
scripted process is being created. The issue is that if one of the
symbol is not found from the list specified in tombstone, none of the
modules load in scripted process. Even if we ensure symbols are present
in symbol server before creating the scripted process, if the load
address is wrong or if the module is already appended, all module loads
are skipped.
**Solution**: Pass in a custom boolean option arg for every module from
python scripted process plugin which will indicate whether to ignore the
module load error. This will provide the flexibility to user for loading
the successfully fetched modules into target while ignoring the failed
ones
---------
Co-authored-by: rchamala <rachamal@fb.com>
Currently, configuring lldb with cmake with separated stdout and stderr
gives some unnecessary output in stderr which happens since message
statement is used without `[mode]` (See
https://cmake.org/cmake/help/v3.31/command/message.html). This patch
adds mode `STATUS` instead of explicit `--` at the beginning of
messages.
This patch fixes `-Wreturn-type` warnings which happens if LLVM is built
with GCC compiler (14.1 is used for detecting)
Warnings:
```
llvm-project/lldb/source/ValueObject/DILLexer.cpp: In static member function ‘static llvm::StringRef lldb_private::dil::Token::GetTokenName(Kind)’:
llvm-project/lldb/source/ValueObject/DILLexer.cpp:33:1: warning: control reaches end of non-void function [-Wreturn-type]
33 | }
| ^
```
and:
```
llvm-project/lldb/source/DataFormatters/TypeSummary.cpp: In member function ‘virtual std::string lldb_private::TypeSummaryImpl::GetSummaryKindName()’:
llvm-project/lldb/source/DataFormatters/TypeSummary.cpp:62:1: warning: control reaches end of non-void function [-Wreturn-type]
62 | }
| ^
```
Technically, it is a bug in Clang (see #115345), however, UBSan with
Clang should detect these places, therefore it would be nice to provide
a return statement for all possible inputs (even invalid).
The implementation has an optimization which detects the range of line
table entries covered by the function and then only searches for a
matching line between them.
This optimization was interfering with the logic for detecting whether a
line belongs to the function because the first call to FindLineEntry was
made with exact=false, which meant that if the function did not contain
any exact matches, we would just pick the closest line number in that
range, even if it was very far away.
This patch fixes that by first attempting an inexact search across the
entire line table, and then use the (potentially inexact) result of that
for searching within the function. This makes the optimization a less
effective, but I don't think we can differentiate between a line that
belongs to the function (but doesn't have any code) and a line outside
the function without that.
The patch also avoids the use of (deprecated) Function::GetAddressRange
by iterating over the GetAddressRanges result to find the full range of
line entries for the function.
While looking at how to make Function::GetEndLineSourceInfo (which is
only used in "command source") work with discontinuous functions, I
realized there are other corner cases that this function doesn't handle.
The code assumed that the last line entry in the function will also
correspond to the last source line. This is probably true for
unoptimized code, but I don't think we can rely on the optimizer to
preserve this property. What's worse, the code didn't check that the
last line entry belonged to the same file as the first one, so if this
line entry was the result of inlining, we could end up using a line from
a completely different file.
To fix this, I change the algorithm to iterate over all line entries in
the function (which belong to the same file) and find the max line
number out of those. This way we can naturally handle the discontinuous
case as well.
This implementation is going to be slower than the previous one, but I
don't think that matters, because:
- this command is only used rarely, and interactively
- we have plenty of other code which iterates through the line table
I added some basic tests for the function operation. I don't claim the
tests to be comprehensive, or that the function handles all edge cases,
but test framework created here could be used for testing other
fixes/edge cases as well.
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
Details:
--------------
Adding PlatformAIX plugin for a basic lldb build support. The 1st commit
is the original version as in the draft PR which is a PlatformLinux
copy. I have removed some of the code in the next commits.
Please let me know all the other changes required to push the
PlatformAIX changes and avoid any duplication.
Make StreamAsynchronousIO an unique_ptr instead of a shared_ptr. I tried
passing the class by value, but the llvm::raw_ostream forwarder stored
in the Stream parent class isn't movable and I don't think it's worth
changing that. Additionally, there's a few places that expect a
StreamSP, which are easily created from a StreamUP.
Extending the conditionals in `AugmentRegisterInfo` to support
alternative names for lldb.
Fixes#124023
There is an exception with register `X8` which is not covered here but
more details can be found in the issue
https://github.com/llvm/llvm-project/issues/127900.
After (too) much deliberation, I came to the conclusion that this isn't
the right abstraction, as it doesn't behave completely like the standard
upper_bound method. What I really wanted was to get the range of line
entries for a given address range -- so I implement just that.
lower_bound is still useful as a primitive for building other kinds of
lookups.
Should fix the following compile error on Windows:
C:\Python312\include\pyconfig.h(225): error C2371: 'pid_t': redefinition; different basic types
C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\include\lldb/Host/windows/PosixApi.h(80): note: see declaration of 'pid_t'
This patch improves the synchronization of the debugger's output and error
streams using two new abstractions: `LockableStreamFile` and
`LockedStreamFile`.
- `LockableStreamFile` is a wrapper around a `StreamFile` and a mutex. Client
cannot use the `StreamFile` without calling `Lock`, which returns a
`LockedStreamFile`.
- `LockedStreamFile` is an RAII object that locks the stream for the duration
of its existence. As long as you hold on to the returned object you are
permitted to write to the stream. The destruction of the object
automatically flush the output stream.
There are a lot of lldb commands whose result is really one or more
ValueObjects that we then print with the ValueObjectPrinter. Now that we
have the ability to access the SBCommandReturnObject through a callback
(#125006), we can store the resultant ValueObjects in the return object,
allowing an IDE to access the SBValues and do its own rich formatting.
rdar://143965453
A handful of minor improvements to StreamAsynchronousIO:
- Document the class.
- Use a named enum value to distinguishing between stdout and stderr.
- Add missing period to comment.
- Clear the string instead of assigning to it.
- Eliminate color argument.
This makes GetOutputStreamSP and GetErrorStreamSP protected members of
Debugger. Users who want to print to the debugger's stream should use
GetAsyncOutputStreamSP and GetAsyncErrorStreamSP instead and the few
remaining stragglers have been migrated.
The motivation is #123622 and the fact that is hard to fine the last
line entry in a given range. `FindLineEntryByAddress(range_end-1)` is
the best we have, but it's not ideal because it has a magic -1 and that
it relies on there existing a line entry at that address (generally, it
should be there, but if for some case it isn't, we might end up ignoring
the entries that are there (or -- like my incorrect fix in #123622 did
-- iterating through the entire line table).
What we really want is to get the last entry that exists in the given
range. Or, equivalently (and more STL-like) the first entry after that
range. This is what these functions do. I've used the STL names since
they do pretty much exactly what the standard functions do (the main
head-scratcher comes from the fact that our entries represent ranges
rather than single values).
The functions can also be used to simplify the maze of `if` statements
in `FindLineEntryByAddress`, but I'm keeping that as a separate patch.
For now, I'm just adding some unit testing for that function to gain
more confidence that the patch does not change the function behavior.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Mach-O corefiles have LC_NOTE metadata, one LC_NOTE that lldb recognizes
is `main bin spec` which can specify that this is a kernel corefile,
userland corefile, or firmware/standalone corefile. With a userland
corefile, the LC_NOTE would specify the virtual address of the dyld
binary's Mach-O header. lldb would create a Module from that in-memory
binary, find the `dyld_all_image_infos` object in dyld's DATA segment,
and use that object to find all of the binaries present in the corefile.
ProcessMachCore takes the metadata from this LC_NOTE and passes the
address to the DynamicLoader plugin via its `GetImageInfoAddress()`
method, so the DynamicLoader can find all of the binaries and load them
in the Target at their correct virtual addresses.
We have a corefile creator who would prefer to specify the address of
`dyld_all_image_infos` directly, instead of specifying the address of
dyld and parsing that to find the object. DynamicLoaderMacOSX, the
DynamicLoader plugin being used here, will accept either a dyld virtual
address or a `dyld_all_image_infos` virtual address from
ProcessMachCore, and do the correct thing with either value.
lldb's process save-core mach-o corefile reader will continue to specify
the virtual address of the dyld binary.
rdar://144322688
Details:
Make LLDB's TelemetryManager a "plugin" so that vendor can supply
appropriate implementation.
The rest of LLDB code will simply call `TelemetryManager::getInstance`
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
This PR fixes LLDB stepping out, rather than stepping through a C++
thunk. The implementation is based on, and upstreams, the support for
runtime thunks in the Swift fork.
Fixes#43413
This patch adds support for template arguments of
`clang::TemplateArgument::ArgKind::StructuralValue` kind (added in
https://github.com/llvm/llvm-project/pull/78041). These are used for
non-type template parameters such as floating point constants. When LLDB
created `clang::NonTypeTemplateParmDecl`s, it previously assumed
integral values, this patch accounts for structural values too.
Anywhere LLDB assumed a `DW_TAG_template_value_parameter` was
`Integral`, it will now also check for `StructuralValue`, and will
unpack the `TemplateArgument` value and type accordingly.
We can rely on the fact that any `TemplateArgument` of `StructuralValue`
kind that the `DWARFASTParserClang` creates will have a valid value,
because it gets those from `DW_AT_const_value`.
The vast majority of `SyntheticChildrenFrontEnd` subclasses provide
children, and as such implement `MightHaveChildren` with a constant
value of `true`. This change makes `true` the default value. With this
change, `MightHaveChildren` only needs to be implemented by synthetic
providers that can return `false`, which is only 3 subclasses.
- Remove _ap (auto_ptr) suffix with _up (unique_ptr) suffix
- Move forward declaration from IOHandler.h to IOHandlerCursesGUI.h
- Move curses namespace under lldb_private
Motivated by Alex' comment in #126630.
AppleObjCRuntimeV2 prints a warning when we read libobjc.A.dylib from
memory, as a canary to detect that we are reading system binaries out of
memory (which is slow, and we try hard to avoid). But with a corefile,
reading out of "memory" is fine, and may be the only way we can find the
correct binary.
rdar://144322688
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, butt 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 ThreadPlanStepInstruction 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.
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.
I first landed this patch in July 2024 via
https://github.com/llvm/llvm-project/pull/96260
but the CI bots and wider testing found a number of test case failures
that needed to be updated, I reverted it. I've fixed all of those issues
in separate PRs and this change should run cleanly on all the CI bots
now.
rdar://123942164
The information about an enum's best promotion type is discarded after
compilation and is not present in debug info. This patch repeats the
same analysis of each enum value as in the front-end to determine the
best promotion type during DWARF info parsing.
Fixes#86989
We need to iterate through the all symbol context ranges returned by
(since #126505) SymbolContext::GetAddressRange. This also includes a fix
to print the function offsets as signed values.
I've also wanted to check that the addresses which are in the middle of
the function do *not* resolve to the function, but that's not entirely
the case right now. This appears to be a separate issue though, so I've
just left a TODO for now.
This patch adds a new API to `SBType` to retrieve the value of a
template parameter given an index. We re-use the
`TypeSystemClang::GetIntegralTemplateArgument` for this and thus
currently only supports integral non-type template parameters. Types
like float/double are not supported yet.
rdar://144395216
This is a followup to #122440, which changed function-relative
calculations to use the function entry point rather than the lowest
address of the function (but missed this usage). Like in #116777, the
logic is changed to use file addresses instead of section offsets (as
not all parts of the function have to be in the same section).
The llvm versions of these functions do that, so we must to so as well.
Practically this meant that were were unable to correctly un-simplify
the names of some types when using type units, which resulted in type
lookup errors.
I will be changing breakpoint hitting behavior soon, where currently
lldb reports a breakpoint as being hit when a thread is *at* a
BreakpointSite, but possibly has not executed the breakpoint instruction
and trapped yet, to having lldb only report a breakpoint hit when the
breakpoint instruction has actually been executed.
One corner case bug with this change is that when you are stopped at a
breakpoint (that has been hit) on the last instruction of a function,
and you do `finish`, a ThreadPlanStepOut is pushed to the thread's plan
stack to put a breakpoint on the return address and resume execution.
And when the thread is asked to resume, it sees that it is at a
BreakpointSite that has been hit, and pushes a
ThreadPlanStepOverBreakpoint on the thread. The StepOverBreakpoint
plan sees that the thread's state is eStateRunning (not eStateStepping),
so it marks itself as "auto continue" -- so once the breakpoint has
been stepped over, we will execution on the thread.
With current lldb stepping behavior ("a thread *at* a BreakpointSite is
said to have stopped with a breakpoint-hit stop reason, even if the
breakpoint hasn't been executed yet"),
`ThreadPlanStepOverBreakpoint::DoPlanExplainsStop` has a special bit of
code which detects when the thread stops with a eStopReasonBreakpoint.
It first checks if the pc is the same as when we started -- did our
"step instruction" not actually step? -- says the stop reason is
explained. Otherwise it sets auto-continue to false (because we've hit
an *unexpected* breakpoint, and we have advanced past our original pc,
and returns false - the stop reason is not explained.
So we do the "finish", lldb instruction steps, we stop *at* the
return-address breakpoint and lldb sets the thread's stop reason to
breakpoint-hit. ThreadPlanStepOverBreakpoint sees an
eStopReasonBreakpoint, sets its auto-continue to false, and says we
stopped for osme reason other than this plan. (and it will also report
`IsPlanStale()==true` so it will remove itself) Meanwhile the
ThreadPlanStepOut sees that it has stopped in the StackID it wanted to
run to, and return success.
This all changes when stopping at a breakpoint site doesn't report
breakpoint-hit until we actually execute the instruction. Now the
ThraedPlanStepOverBreakpoint looks at the thread's stop reason, it's
eStopReasonTrace (we've instruction stepped), and so it leaves its
auto-continue to `true`. ThreadPlanStepOut sees that it has reached its
goal StackID, removes its breakpoint, and says it is done.
Thread::ShouldStop thinks the auto-continue == yes vote from
ThreadPlanStepOverBreakpoint wins, and we lose control of the process.
This patch changes ThreadPlanStepOut to require that *both* (1) we are
at the StackID of the caller function, where we wanted to end up, and
(2) we have actually hit the breakpoint that we inserted.
This in effect means that now lldb instruction-steps over the breakpoint
in the callee function, stops at the return address of the caller
function. StepOverBreakpoint has completed. StepOut is still running,
and we continue the thread again. We immediatley hit the breakpoint
(that we're sitting at), and now ThreadPlanStepOut marks itself as
completed, and we return control to the user.
Jim suggests that ThreadPlanStepOverBreakpoint is a bit unusual because
it's not something pushed on the stack by a higher-order thread plan
that "owns" it, it is inserted by the Thread as it is about to resume,
if we're at a BreakpointSite. It has no connection to the thread plans
above it, but tries to set the auto-continue mode based on the state of
the thread when it is inserted (and tries to detect an unexpected
breakpoint and unset that auto-continue it previously decided on,
because it now realizes it should not influence execution control any
more). Instead maybe the
ThreadPlanStepOverBreakpoint should be inserted as a child plan of
whatever the lowest plan is on the stack at the point it is added.
I added an API test that will catch this bug in the new thread
breakpoint algorithm.
Remove Debugger::GetOutputStream and Debugger::GetErrorStream in
preparation for replacing both with a new variant that needs to be
locked and hence can't be handed out like we do right now.
The patch replaces most uses with GetAsyncOutputStream and
GetAsyncErrorStream respectively. There methods return new StreamSP
objects that automatically get flushed on destruction.
See #126630 for more details.
Background:
Telemetry code isn't always built (controlled by this
LLVM_BUILD_TELEMETRY cmake flag)
This means users of the library may not have the library. So we're
definding the `-DLLVM_BUILD_TELEMETRY` to be used in ifdef.
The command already supported disassembling multiple ranges, among other
reasons because inline functions can be discontinuous. The main thing
that was missing was being able to retrieve the function ranges from the
top level function object.
The output of the command for the case where the function entry point is
not its lowest address is somewhat confusing (we're showing negative
offsets), but it is correct.
Nobody is overriding GetValueProperties, so in practice we're always
using `m_collection_sp`, which means we don't need to check the pointer.
The temlated helpers were already operating on `m_collection_sp`
directly so this makes the rest of the class consistent.
This typedef doesn't match the signature below, specifically the
signature takes a `lldb:SBDebugger` vs this was defined as
`lldb:SBDebugger&`.
```
lldb/source/API/SBDebugger.cpp:199:13: runtime error: call to function lldb::PluginInitialize(lldb::SBDebugger) through pointer to incorrect function type 'bool (*)(lldb::SBDebugger &)'
.../CustomPlugin.cpp:134: note: lldb::PluginInitialize(lldb::SBDebugger) defined here
```
Use a preprocessor `#ifdef LLVM_BUILD_TELEMETRY` guard rather than
`PARTIAL_SOURCES_INTENDED` for the `Telemetry.cpp` file, to fix building
with telemetry disabled. `PARTIAL_SOURCES_INTENDED` does not currently
work in `lldb_add_library()`, and while it could be fixed, it seems to
be used contrary to its purpose — in other parts of LLVM project, the
option is used to indicate that the sources found in the directory are
split between different targets (e.g. a library and a tool), not to
include sources conditionally.
A section of ObjectFileMachO is ifdef compiled only when
building to run on iOS etc natively, so this old method
call rename wasn't detected by normal on-mac building.
A DriverKit process is a kernel extension that runs in userland, instead
of running in the kernel address space/priv levels, they've been around
a couple of years. From lldb's perspective a DriverKit process is no
different from any other userland level process, but it has a different
Triple so we need to handle those cases in the lldb codebase. Some of
the DriverKit triple handling had been upstreamed to llvm-project, but I
noticed a few cases that had not yet. Cleaning that up.
Details:
- This is a subset of PR/98528.( Pavel's suggestion was to split up the
patch to make reviewing easier)
- This contains only the concrete implementation of the framework to be
used but no usages yet.
- I plan to send a few follow-up patches:
+ part2 : includes changes in the plugin-manager to set up the plugin
stuff (ie., how to create a default vs vendor impl)
+ part3 (all of the following can be done in parallel):
* part 3_a: define DebuggerTelemetryInfo and related methods to collect
data about debugger startup/exit
* part 3_b: define TargetTelemetryInfo and related methods to collect
data about debug target(s)
* part 3_c: define CommandTelemetryInfo and related methods to collect
data about debug-commands
* part 3_d: define ClientTelemtryInfo and related methods to collect
data about lldb-dap/any other client
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Recognize the visionOS Triple::OSType::XROS os type. Some of these have
already been landed on main, but I reviewed the downstream sources and
there were a few that still needed to be landed upstream.
This patch consumes the `DW_AT_APPLE_enum_kind` attribute added in
https://github.com/llvm/llvm-project/pull/124752 and turns it into a
Clang attribute in the AST. This will currently be used by the Swift
language plugin when it creates `EnumDecl`s from debug-info and passes
it to Swift compiler, which expects these attributes
