Allow the ObjectFileELF plugin to resolve R_ARM_ABS32 relocations from AArch32 object files. This fixes https://github.com/llvm/llvm-project/issues/61948
The existing architectures work with RELA-type relocation records that read addend from the relocation entry. REL-type relocations in AArch32 store addend in-place.
The new function doesn't re-use ELFRelocation::RelocAddend32(), because the interface doesn't match: in addition to the relocation entry we need the actual target section memory.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D147642
Refactor the debugserver watchpiont support in anticipating of
adding support for AArch64 MASK hardware watchpoints to watch
larger regions of memory. debugserver already had support for
handling a request to watch an unaligned region of memory up
to 8 bytes using Byte Address Select watchpoints - it would split
an unaligned watch request into two aligned doublewords that
could be watched with two hardware watchpoints using the BAS
specification.
This patch generalizes that code for properly aligning, and
possibly splitting, a watchpoint request into two hardware watchpoints
to handle any size request. And separates out the specifics
about BAS watchpoints into its own method, so a sibling method
for MASK watchpoints can be dropped in next.
Differential Revision: https://reviews.llvm.org/D149040
rdar://108233371
i386 and armv7 macOS/iOS cannot be built with current Xcode
any longer; we cannot build or test the support code for running
debugserver on these targets. Remove the code.
Differential Revision: https://reviews.llvm.org/D149503
This patch refactors the macOS implementation of
OpenFileInExternalEditor. It fixes an AppleEvent memory leak, the
caching of LLDB_EXTERNAL_EDITOR and speculatively fixes a crash when
CFURL is NULL (rdar://108633464). The new code also improves error
handling, readability and documents calls to the CoreFoundation Launch
Services APIs.
A bunch of the Launch Services APIs have been deprecated
(LSFindApplicationForInfo, LSOpenURLsWithRole). The preferred API is
LSOpenCFURLRef but it doesn't specifying the "location" Apple Event
which is used to highlight the current line and switching over would
regress the existing behavior.
rdar://108633464
Differential revision: https://reviews.llvm.org/D149482
In 27f27d15f6c9, we added a new way to use textual (JSON) object files
and symbol files with the interactive crashlog command, using the
inlined symbols from the crash report.
However, there was a missing piece after successfully adding the textual
module to the target, we didn't mark it as available causing the module
loading to exit early.
This patch addresses that issue by marking the module as available when
added successfully to the target.
Differential Revision: https://reviews.llvm.org/D149477
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This generalises the GetXcodeSDKPath hook to a GetSDKRoot path which
will be re-used for the Windows support to compute a language specific
SDK path on the platform. Because there may be other options that we
wish to use to compute the SDK path, sink the XcodeSDK parameter into
a structure which can pass a disaggregated set of options. Furthermore,
optionalise the parameter as Xcode is not available for all platforms.
Differential Revision: https://reviews.llvm.org/D149397
Reviewed By: JDevlieghere
This was using `struct data` which is way to common a name to use in
an lldb expression, and was causing occasional failures in the
TSan report gatherer. The structure doesn't need to have a tag,
so remove it to avoid future problems.
The same job was done for the other sanitizers in D145569, but this
one was overlooked.
Differential Revision: https://reviews.llvm.org/D149394
Use correct internal sve functions for arm64.
Otherwise, when cross-compling lld for AArch64 there are build
errors like:
NativeRegisterContextLinux_arm64.cpp:936:11:
error: use of undeclared identifier 'sve_vl_valid
NativeRegisterContextLinux_arm64.cpp:63:28:
error: variable has incomplete type 'struct user_sve_header'
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D148752
Some LLDB set ups need to hide certain commands for security reasons, so I'm adding a flag that allows removing non-user commands.
Differential Revision: https://reviews.llvm.org/D149312
These don't really need to be in ConstStrings. It's nice that comparing
ConstStrings is fast (just a pointer comparison) but the cost of
creating the ConstString usually already includes the cost of doing a
StringRef comparison anyway, so this is just extra work and extra memory
consumption for basically no benefit.
Differential Revision: https://reviews.llvm.org/D149300
Jason isn't sure what this is used for and isn't aware of a .Bundle
suffix related to kernel debugging. Let's remove it.
Differential Revision: https://reviews.llvm.org/D149284
The sanity check on the size of the register context we found in
the corefile was off by one, so lldb would not add the register
contents. Add a test case to ensure it doesn't regress.
Differential Revision: https://reviews.llvm.org/D149224
rdar://108306070
This is useful in contexts where you have multiple languages in play:
You may be stopped in a frame for language A, but want to set a watchpoint
with an expression using language B. The current way to do this is to
use the setting `target.language` while setting the watchpoint and
unset it after the watchpoint is set, but that's kind of clunky and
somewhat error-prone. This should add a better way to do this.
rdar://108202559
Differential Revision: https://reviews.llvm.org/D149111
In 6c961ae, I've introduced a new explicit fully specialized templated method
`ScriptedPythonInterface::ReverseTransform(bool&, PythonObject, Status&)`.
However, that explicit specialization is causing GCC to choke when
building the file as shown here:
https://lab.llvm.org/buildbot/#/builders/217/builds/20430
To address that issue, this patch turns the method explicit specialization
into an method overload.
Differential Revision: https://reviews.llvm.org/D149218
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This should fix a test failure in TestInteractiveScriptedProcess.py
caused by a missing decorator added in d0d902d.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improve the interactive scripted process debugging test by
adding test coverage for child process breakpoint setting and execution
state change.
This patch introduces a new test case for a multiplexed launch, which
does the same thing as the simple passthrough launch. After the
multiplexer process stops, this new test launches 2 other scripted processes
that should contain respectively the even and odd threads from the
multiplexer scripted process.
Then, we create a breakpoint on one the child scripted process, make
sure it was set probably on the child process, the multiplexer process
and the real process. This also test the breakpoint name tagging at the
multiplexer level.
Finally, we resume the child process that had a breakpoint and make sure
that all the processes has stopped at the right location.
Differential Revision: https://reviews.llvm.org/D149179
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch updates the `lldbutil.fetch_next_event` helper function to
either match a specific broadcaster or match a whole broadcaster class.
This is very handy when testing process events for interactive scripted
process debugging.
This also fixes a bug in the failing case, where `SBEvent.GetDescription`
expects a `SBStream` argument. We never took that code path in the
original implementation so we didn't hit that bug.
Differential Revision: https://reviews.llvm.org/D149175
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves breakpoint management when doing interactive
scripted process debugging.
In other to know which process set a breakpoint, we need to do some book
keeping on the multiplexer scripted process. When initializing the
multiplexer, we will first copy breakpoints that are already set on the
driving target.
Everytime we launch or resume, we should copy breakpoints from the
multiplexer to the driving process.
When creating a breakpoint from a child process, it needs to be set both
on the multiplexer and on the driving process. We also tag the created
breakpoint with the name and pid of the originator process.
This patch also implements all the requirement to achieve proper
breakpoint management. That involves:
- Adding python interator for breakpoints and watchpoints in SBTarget
- Add a new `ScriptedProcess.create_breakpoint` python method
Differential Revision: https://reviews.llvm.org/D148548
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is a proof of concept that shows how a scripted process could
be used with real process to perform interactive debugging.
In this example, we run a process that spawns 10 threads.
That process gets launched by an intermediary scripted process who's job
is to intercept all of it's process events and dispatching them
back either to the real process or to other child scripted processes.
In this example, we have 2 child scripted processes, with even and odd
thread indices. The goal is to be able to do thread filtering and
explore the various interactive debugging approaches, by letting a child
process running when stopping the other process and inspecting it.
Another approach would be to have the child processes execution in-sync
to force running every child process when one of them starts running.
Differential Revision: https://reviews.llvm.org/D145297
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new convience constructor to the SBError to initialize
it with a string message to avoid having to create the object and call
the `SetErrorString` method afterwards.
This is very handy to report errors from lldb scripted affordances.
Differential Revision: https://reviews.llvm.org/D148401
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds support for breakpoint setting to Scripted Processes.
For now, Scripted Processes only support setting software breakpoints.
When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.
Differential Revision: https://reviews.llvm.org/D145296
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves process state change logging messages to include to
process plugin name.
It also replaces the `LLDB_LOGF` macro by `LLDB_LOG` macro that adds the
class and method name in the log message using the compiler instead of
having to change the string litteral for every method.
This is very useful when investigating interactions between different
types of process plugins. That comes very handy when investigating bugs
related to interactive scripted process debugging.
Differential Revision: https://reviews.llvm.org/D148399
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch augments lldb's event listeners with a new shadow mode.
As the name suggests, this mode allows events to be copied to an
additional listener to perform event monitoring, without interferring
with the event life cycle.
One of our use case for this, is to be able to listen to public process
events while making sure the events will still be delivered to the
default process listener (the debugger listener in most cases).
Differential Revision: https://reviews.llvm.org/D148397
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is a simple refactor that unifies the default and hijack
listener methods and attributes between ProcessAttachInfo and
ProcessLaunchInfo.
These 2 classes are both derived from the ProcessInfo base class so this
patch moves the listeners attributes and getter/setter methods to the
base class.
Differential Revision: https://reviews.llvm.org/D148395
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle its private
state from running to stopped, which will result in broadcasting a
process state changed event to the debugger listener.
Originally, this state update was done systematically in the Scripted
Process C++ plugin, however in order to make scripted process
interactive, we need to be able to update their state dynamically.
This patch makes use of the recent addition of the
SBProcess::ForceScriptedState to programatically, and moves the
process private state update to the python implementation of the resume
method instead of doing it in ScriptedProcess::DoResume.
This patch also removes the unused ShouldStop & Stop scripted
process APIs, and adds new ScriptedInterface transform methods for
boolean arguments. This allow the user to programmatically decide if
after running the process, we should stop it (which is the default setting).
Differential Revision: https://reviews.llvm.org/D145295
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new method to the SBProcess API called
ForceScriptedState. As the name suggests, this affordance will allow the
user to alter the state of the scripted process programatically.
This is necessary to update the scripted process state when perform
interactive debugging.
Differential Revision: https://reviews.llvm.org/D145294
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This change ensures that the REPL map inside Target is destroyed correctly when `Target::Destroy()` is invoked. Not doing so results in the REPL not finishing its job when the debugger is initialized in REPL mode reading from a file. In my particular case, my REPL doesn't print the stdout of the last expression in the input file unless I include this change.
Differential Revision: https://reviews.llvm.org/D149180
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.
This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.
However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.
So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.
Differential Revision: https://reviews.llvm.org/D148863
It was avoiding a crash at the time on macOS, apparently, and
it skipped the test on all platforms. This test passes for me
now on macOS, let's remove the skip and see how the bots go.
We have a handful of places in LLDB where we try to outsmart the logic
in Mangled to determine whether a string is mangled or not. There's at
least one place (*) where we are getting this wrong and causes a subtle
bug. The `cstring_is_mangled` is cheap enough that we should always rely
on it to determine whether a string is mangled or not.
(*) `ObjectFileMachO` assumes that a symbol that starts with a double
underscore (such as `__pthread_kill`) is mangled. That's mostly
harmless, until you use `function.name-without-args` in the frame
format. The formatter calls `Symbol::GetNameNoArguments()` which is a
wrapper around `Mangled::GetName(ePreferDemangledWithoutArguments)`. The
latter will first try using the appropriate language plugin to get the
demangled name without arguments, and if that fails, falls back to
returning the demangled name. Because we forced Mangled to treat the
symbol as a mangled name (even though it's not) there's no demangled
name. The result is that frames don't show any symbol at all.
Differential revision: https://reviews.llvm.org/D148846
I received a crash report in DiagnosticManager that was caused by a
nullptr diagnostic having been added. The API allows passing in a null
unique_ptr, but all the methods are written assuming that all pointers
a dereferencable. This patch makes it impossible to add a null
diagnostic.
rdar://107633615
Differential Revision: https://reviews.llvm.org/D148823
Previously if a register had fields we would always print them after the
value if the register was asked for by name.
```
(lldb) register read MDCR_EL3
MDCR_EL3 = 0x00000000
= {
ETBAD = 0
<...>
RLTE = 0
}
```
This can be quite annoying if there are a whole lot of fields but you
want to see the register in a specific format.
```
(lldb) register read MDCR_EL3 -f i
MDCR_EL3 = 0x00000000 unknown udf #0x0
= {
ETBAD = 0
<...lots of fields...>
```
Since it pushes the interesting bit far up the terminal. To solve this,
don't print fields if the user passes --format. If they're doing that
then I think it's reasonable to assume they know what they want and only
want to see that output.
This also gives users a way to silence fields, but not change the format.
By doing `register read foo -f x`. In case they are not useful or perhaps
they are trying to work around a crash.
I have customised the help text for --format for register read to explain this:
```
-f <format> ( --format <format> )
Specify a format to be used for display. If this is set, register fields will not be dispayed.
```
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D148790
/home/jiefu/llvm-project/lldb/source/Target/PathMappingList.cpp:51:5: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock locks(m_mutex, rhs.m_mutex);
^
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
/home/jiefu/llvm-project/lldb/source/Target/PathMappingList.cpp:72:3: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
std::scoped_lock locks(m_mutex, rhs.m_mutex);
^
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
class scoped_lock
^
2 errors generated.
This reverts commit d81cdb49d74064e88843733e7da92db865943509.
This refactoring was waiting on converting LLVM to C++17.
Leave StringView.h and cleanup around for subsequent cleanup.
Additional fixes for missing std::string_view conversions for MSVC.
Reviewed By: MaskRay, DavidSpickett, ayzhao
Differential Revision: https://reviews.llvm.org/D148546
In the particular case I was looking at I autogenerated a 128 bit set
of flags that is only 64 bit. This doesn't crash lldb but it was certainly
not expected.
I suspect that we would have crashed if the top 64 bits weren't
marked as unused (or at least invoked some very undefined behaviour).
When this happens, log the details and ignore the flags. Like this:
```
Size of register flags TTBR0_EL1_flags (16 bytes) for register TTBR0_EL1 does not match the register size (8 bytes). Ignoring this set of flags.
```
Turns out a few of the tests relied on this bug so I have updated
them and added a specific test for this case.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D148715
This patch should address an issue that caused the process public run
lock to not be updated during a process launch/attach when the process
stops.
That caused the public run lock to report its state as running while the
process state is stopped. This prevents the users to interact with the
process (through the command line or via the SBAPI) since it's
considered still running.
To address that, this patch refactors the name of the internal hijack
listeners to a specific pattern `lldb.internal.<action>.hijack` that
are used to ensure that we've attached to or launched a process successfully.
Then, when updating the process public state, after updating the state
value, if the process is not hijacked externally, meaning if the process
doens't have a hijack listener that matches the internal hijack
listeners pattern, we can update the public run lock accordingly.
rdar://108283017
Differential Revision: https://reviews.llvm.org/D148400
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.
Differential Revision: https://reviews.llvm.org/D148679
