Instead of looking up a symbol and reducing it to an addr_t to set
a breakpoint, set the breakpoint on the function name directly.
The old Mac OS X dynamic loader plugin worked in terms of addresses
and I incorrectly emulated that here when I wrote this newer one.
Differential Revision: https://reviews.llvm.org/D100931
Enable reporting fork/vfork events to the server when supported.
At this moment, this is used only to test the server code, as real
client does not report fork-events and vfork-events as supported.
Differential Revision: https://reviews.llvm.org/D100208
Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet. A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.
Differential Revision: https://reviews.llvm.org/D100191
Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.
Differential Revision: https://reviews.llvm.org/D100196
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them. LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin. If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.
The extension is enabled on the process instance by calling
SetEnabledExtensions() method. This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.
The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'. Both
features rely on 'multiprocess+' being supported as well.
Differential Revision: https://reviews.llvm.org/D100153
A couple of our Instrumentation runtimes were gathering backtraces,
storing it in a StructuredData array and later creating a HistoryThread
using this data. By deafult HistoryThread will consider the history PCs
as return addresses and thus will substract 1 from them to go to the
call address.
This is usually correct, but it's also wasteful as when we gather the
backtraces ourselves, we have much better information to decide how
to backtrace and symbolicate. This patch uses the new
GetFrameCodeAddressForSymbolication() to gather the PCs that should
be used for symbolication and configures the HistoryThread to just
use those PCs as-is.
(The MTC plugin was actaully applying a -1 itself and then the
HistoryThread would do it again, so this actaully fixes a bug there.)
rdar://77027680
Differential Revision: https://reviews.llvm.org/D101094
The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.
The `--top-level` flag parses and injects the code as if its in the top level
scope of a source file.
Both flags just change the ExecutionPolicy of the expression:
* `--allow-jit true` -> doesn't change anything (its the default)
* `--allow-jit false` -> ExecutionPolicyNever
* `--top-level` -> ExecutionPolicyTopLevel
Passing `--allow-jit false` and `--top-level` currently causes the `--top-level`
to silently overwrite the ExecutionPolicy value that was set by `--allow-jit
false`. There isn't any ExecutionPolicy value that says "top-level but only
interpret", so I would say we reject this combination of flags until someone
finds time to refactor top-level feature out of the ExecutionPolicy enum.
The SBExpressionOptions suffer from a similar symptom as `SetTopLevel` and
`SetAllowJIT` just silently disable each other. But those functions don't have
any error handling, so not a lot we can do about this in the meantime.
Reviewed By: labath, kastiglione
Differential Revision: https://reviews.llvm.org/D91780
`InsertSequence` doesn't take ownership of the pointer so releasing this pointer
is just leaking memory.
Follow up to D100806 that was fixing other leak sanitizer test failures
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D100846
At the moment the expression parser doesn't support evaluating expressions in
static member functions and just pretends the expression is evaluated within a
non-member function. This causes that all static members are inaccessible when
doing unqualified name lookup.
This patch adds support for evaluating in static member functions. It
essentially just does the same setup as what LLDB is already doing for
non-static member functions (i.e., wrapping the expression in a fake member
function) with the difference that we now mark the wrapping function as static
(to prevent access to non-static members).
Reviewed By: shafik, jarin
Differential Revision: https://reviews.llvm.org/D81550
`RichManglingContext::FromCxxMethodName` allocates a m_cxx_method_parser, but never deletes it.
This fixes a `-DLLVM_USE_SANITIZER=Leaks` failure.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D100795
Just fixing a few things I noticed as I am working on another feature for format
strings in the prompt: forward decls, adding constexpr constructors, various
checks, and unit tests for FormatEntity::Parse and new Definition constructors,
etc.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D98153
Support registering multiple callbacks for a single signal. This is
necessary to support multiple co-existing native process instances, with
separate SIGCHLD handlers.
The system signal handler is registered on first request, additional
callback are added on subsequent requests. The system signal handler
is removed when last callback is unregistered.
Differential Revision: https://reviews.llvm.org/D100418
The code used the total number of symbols to create a symbol ID for the
synthetic symbols. This is not correct because the IDs of real symbols
can be higher than their total number, as we do not add all symbols (and
in particular, we never add symbol zero, which is not a real symbol).
This meant we could have symbols with duplicate IDs, which caused
problems if some relocations were referring to the duplicated IDs. This
was the cause of the failure of the test D97786.
This patch fixes the code to use the ID of the highest (last) symbol
instead.
Landing this fix for Augusto Noronha. The code is getting the
Section from 'addr' passed in, but it may have been expressed as
a load address when it was created and Target::ReadMemory tries to
convert it to a Section+offset if that's now possible; use the
Section found from that cleanup if it exists.
Differential Revision: https://reviews.llvm.org/D100850
Commiting this patch for Augusto Noronha who is getting set
up still.
This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory. Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.
rdar://30634422
Differential revision: https://reviews.llvm.org/D100338
Read the number of addressable bits from the qHostInfo packet and use it
to set the code and data address mask in the process. The data
(addressing_bits) is already present in the packet.
Differential revision: https://reviews.llvm.org/D100520
Implement FixCodeAddress and FixDataAddress for ABIMacOSX_arm64 and
ABISysV_arm64 and add missing calls to RegisterContextUnwind. We need
this to unwind on Apple Silicon where libraries like libSystem are
arm64e even when the program being debugged is arm64.
Differential revision: https://reviews.llvm.org/D100521
Add a code and data address mask to Process with respective getters and
setters and a setting that allows the user to specify the mast as a
number of addressable bits. The masks will be used by FixCodeAddress and
FixDataAddress respectively in the ABI classes.
Differential revision: https://reviews.llvm.org/D100515
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
The armv6m entry in cores_match() got separated from its
friends armv7m and armv7em. Reuniting them to make it
easier to keep them updated in all at the same time.
We have seen several crashes in LibCppStdFunctionCallableInfo(...) but we don't have a
reproducer. The last crash pointed to last call to line_entry_helper(...) and symbol
was a nullptr. So adding a check for this case.
It looks like the goal of this code is to provide a more precise
architecture definition for the target when attaching to a process. When
attaching to a foreign debugserver, you might get into a situation where
the active (host) platform will give you bogus information on the target
process.
This change allows the platform to override the target arch only with a
compatible architecture. This fixes TestTargetXMLArch.py on Apple
Silicon. Another alternative would be to just fail in this scenario and
update the test(s).
These were in the shared llgs+platform code, but they only make sense
for llgs (as they deal with how the server reports information about
debugged processes).
Also remove a superfluous semicolon after the braces for a switch
statement (that wasn't warned about).
Differential Revision: https://reviews.llvm.org/D100447
Introduce new m_current_process and m_continue_process variables that
keep the pointers to currently selected process. At this moment, this
is equivalent to m_debugged_process_up but it lays foundations for
the future multiprocess support.
Differential Revision: https://reviews.llvm.org/D100256
The original commit was reverted because of the problems it introduced
on Linux. However, FreeBSD should not be affected, so restore that part
and we will address Linux separately.
While at it, remove the dbreg hack as the underlying issue has been
fixed in the FreeBSD kernel and the problem is unlikely to happen
in real life use anyway.
Differential Revision: https://reviews.llvm.org/D98822
Refactor handling qSupported to use a virtual HandleFeatures() method.
The client-provided features are split into an array and passed
to the method. The method returns an array of server features that are
concatenated into the qSupported response to the server.
The base implementation of HandleFeatures()
in GDBRemoteCommunicationServerCommon now includes only flags common
to both platform server and llgs, while llgs-specific flags are inserted
in GDBRemoteCommunicationServerLLGS.
Differential Revision: https://reviews.llvm.org/D100140
Refactor the qSupported handler to split the reply into an array,
and identify features within the array rather than searching the string
for partial matches. While at it, use StringRef.split() to process
the compression list instead of reinventing the wheel.
Switch the arguments to MaybeEnableCompression() to use an ArrayRef
of StringRefs to simplify parameter passing from GetRemoteQSupported().
Differential Revision: https://reviews.llvm.org/D100146
This commit has caused the following tests to be flaky:
TestThreadSpecificBpPlusCondition.py
TestExitDuringExpression.py
The exact cause is not known yet, but since both tests deal with
threads, my guess is it has something to do with the tracking of
creation of new threads (which the commit touches upon).
This reverts the following commits:
d01bff8cbd,
ba62ebc48e,
e761b6b4c5,
a345419ee0.
In all this time, we've never used more than one delegate. The logic to
support multiple delegates is therefore untested, and becomes
particularly unwieldy once we need to support multiple processes.
Just remove it.
This reverts commit 3842de49f6.
It fails to build, with errors such as:
GDBRemoteCommunicationClient.cpp:1005:20:
error: no viable overloaded '='
avail_name = compression;
Refactor the qSupported handler to split the reply into an array,
and identify features within the array rather than searching the string
for partial matches. While at it, use StringRef.split() to process
the compression list instead of reinventing the wheel.
Switch the arguments to MaybeEnableCompression() to use an ArrayRef
of StringRefs to simplify parameter passing from GetRemoteQSupported().
Differential Revision: https://reviews.llvm.org/D100146
That code is unused since it's check-in in 2010 (and I believe it would leak
memory when called as it releases the passed unique_ptr), so let's delete it.
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D100212
When LLDB's DWARF parser is parsing the member DIEs of a struct/class it
currently fully resolves the types of static member variables in a class before
adding the respective `VarDecl` to the record.
For record types fully resolving the type will also parse the member DIEs of the
respective class. The other way of resolving is just 'forward' resolving the type
which will try to load only the minimum amount of information about the type
(for records that would only be the name/kind of the type). Usually we always
resolve types on-demand so it's rarely useful to speculatively fully resolve
them on the first use.
This patch changes makes that we only 'forward' resolve the types of static
members. This solves the fact that LLDB unnecessarily loads debug information
to parse the type if it's maybe not needed later and it also avoids a crash where
the parsed type might in turn reference the surrounding class that is currently
being parsed.
The new test case demonstrates the crash that might happen. The crash happens
with the following steps:
1. We parse class `ToLayout` and it's members.
2. We parse the static class member and fully resolve its type
(`DependsOnParam2<ToLayout>`).
3. That type has a non-static class member `DependsOnParam1<ToLayout>` for which
LLDB will try to calculate the size.
4. The layout (and size)`DependsOnParam1<ToLayout>` turns depends on the
`ToLayout` size/layout.
5. Clang will calculate the record layout/size for `ToLayout` even though we are
currently parsing it and it's missing it's non-static member.
The created is missing the offset for the yet unparsed non-static member. If we
later try to get the offset we end up hitting different asserts. Most common is
the one in `TypeSystemClang::DumpValue` where it checks that the record layout
has offsets for the current FieldDecl.
```
assert(field_idx < record_layout.getFieldCount());
```
Fixed rdar://67910011
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D100180
When debugging LanguageRuntime unwindplans, it can be
helpful to disable their use and see the normal
stack walk. Add a setting for this.
Differential Revision: https://reviews.llvm.org/D99828
Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux)
notifications and explicitly detach the forked child process, and add
initial tests for these cases. The code covers FreeBSD, Linux
and NetBSD process plugins. There is no new user-visible functionality
provided -- this change lays foundations over subsequent work on fork
support.
Differential Revision: https://reviews.llvm.org/D98822
If the debug info is missing the terminating null die, we would crash
when trying to access the nonexisting children/siblings. This was
discovered because the test case for D98619 accidentaly produced such
input.
Emre Kultursay