This patch pull offset calculation logic out of DynamicRegisterInfo::Finalize
into a separate function. We are going to call this function whenever we
update SVE register sizes.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D94008
In gdb-remote process we have register infos defind as a refernce object of
GDBRemoteDynamicRegisterInfo class. In past register infos have remained
constant througout the life time of a process.
This has changed after AArch64 SVE support where register infos will have
per-thread configuration. SVE registers will have per-thread size and can
be updated while running. This patch aims to build up for that support by
changing GDBRemoteDynamicRegisterInfo reference to a shared pointer deinfed
per-thread.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82857
When a program maps one of its own modules for reading, and then
crashes, breakpad can emit two entries for that module in the
ModuleList. We have logic to identify this case by checking permissions
on mapped memory regions and report just the module with an executable
region. As currently written, though, the check is asymmetric -- the
entry with the executable region must be the second one encountered for
the preference to kick in.
This change makes the logic symmetric, so that the first-encountered
module will similarly be preferred if it has an executable region but
the second-encountered module does not. This happens for example when
the module in question is the executable itself, which breakpad likes to
report first -- we need to ignore the other entry for that module when
we see it later, even though it may be mapped at a lower virtual
address.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D94629
The test was marked as remote-only, which means it was run ~never, and
accumulated various problems. This commit modifies the test to run
locally and includes a couple of other fixes necessary to make it run:
- moves the "invoke" method into the "Base" test class
- adds []'s around the IP address in a couple more places to make things
work with IPv6
The test is now marked as skipped when running the remote test suite. It
would be possible to make it run both locally and remotely, but this
would require writing a lot special logic for the remote case, and that
is not worth it.
This commit vAttachWait in lldb-server, so --waitfor can be used on
Linux
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D93895
- s/createUniqueFile/createUniquePath -- we don't want to create the file,
just the file name
- s/data()/str().c_str()/ -- paths given to system apis must be
null-terminated
Replace uses of GetModuleAtIndexUnlocked and
GetModulePointerAtIndexUnlocked with the ModuleIterable and
ModuleIterableNoLocking where applicable.
Differential revision: https://reviews.llvm.org/D94271
Adds the RISC-V ArchSpec bits contributed by @simoncook as part of D62732,
plus logic to distinguish between riscv32 and riscv64 based on ELF class.
The patch follows the implementation approach previously used for MIPS.
It defines RISC-V architecture subtypes and inspects the ELF header,
namely the ELF class, to detect the right subtype.
Differential Revision: https://reviews.llvm.org/D86292
gcc already produces debug info with this form
-freorder-block-and-partition
clang produces this sort of thing with -fbasic-block-sections and with a
coming-soon tweak to use ranges in DWARFv5 where they can allow greater
reuse of debug_addr than the low/high_pc forms.
This fixes the case of breaking on a function name, but leaves broken
printing a variable - a follow-up commit will add that and improve the
test case to match.
Differential Revision: https://reviews.llvm.org/D94063
Add optional memory tagging extension on AArch64.
Use isAArch64() instead of listing the AArch64 triples,
which fixes us not recognising aarch64_be.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D94084
1 - Partial Statements
The interpreter loop runs every line it receives, so partial
Lua statements are not being handled properly. This is a problem for
multiline breakpoint scripts since the interpreter loop, for this
particular case, is just an abstraction to a partially parsed function
body declaration.
This patch addresses this issue and as a side effect improves the
general Lua interpreter loop as well. It's now possible to write partial
statements in the 'script' command.
Example:
(lldb) script
>>> do
..> local a = 123
..> print(a)
..> end
123
The technique implemented is the same as the one employed by Lua's own REPL implementation.
Partial statements always errors out with the '<eof>' tag in the error
message.
2 - CheckSyntax in Lua.h
In order to support (1), we need an API for just checking the syntax of string buffers.
3 - Multiline scripted breakpoints
Finally, with all the base features implemented this feature is
straightforward. The interpreter loop behaves exactly the same, the
difference is that it will aggregate all Lua statements into the body of
the breakpoint function. An explicit 'quit' statement is needed to exit the
interpreter loop.
Example:
(lldb) breakpoint command add -s lua
Enter your Lua command(s). Type 'quit' to end.
The commands are compiled as the body of the following Lua function
function (frame, bp_loc, ...) end
..> print(456)
..> a = 123
..> quit
Differential Revision: https://reviews.llvm.org/D93481
Emit os_signposts when supported from LLDB's timer class. A vast amount
of performance sensitive places in LLDB are already instrumented with
the Timer class.
By emitting signposts we can examine this information in Instruments. I
recommend looking at Daniel's differential for why this is so powerful:
https://reviews.llvm.org/D52954.
Differential revision: https://reviews.llvm.org/D93657
In split DWARF v5 files, the DWO id is no longer in the DW_AT_GNU_dwo_id
attribute. It's in the CU header instead. This change makes lldb look in
both places.
Differential Revision: https://reviews.llvm.org/D93444
Copy changes, including:
- NativeProcessNetBSD::GetLoadedModuleFileSpec()
and NativeProcessNetBSD::GetFileLoadAddress() methods
- split x86 register sets by CPU extensions
- use offset/size-based register reading/writing
Differential Revision: https://reviews.llvm.org/D93541
As of Linux 5.10, the kernel may report either of the two following
crash reasons:
- SEGV_MTEAERR: async MTE tag check fault
- SEGV_MTESERR: sync MTE tag check fault
Teach LLDB about them.
Differential Revision: https://reviews.llvm.org/D93495
GetCommandSPExact is called exaclty once with include_aliases set to
true, so make it a default argument. Use early returns to simplify the
implementation.
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to the
LLDB_LOG(F) macro.
Differential revision: https://reviews.llvm.org/D93663
This is a speculative fix when looking at the finalization code in
Process. It tackles the following issues:
- Adds synchronization to prevent races between threads.
- Marks the process as finalized/invalid as soon as Finalize is called
rather than at the end.
- Simplifies the code by using only a single instance variable to track
finalization.
Differential revision: https://reviews.llvm.org/D93479
Use RegSetKind enum for register sets everything, rather than int.
Always spell it as 'RegSetKind', without unnecessary 'enum'. Add
missing switch case. While at it, use uint32_t for regnums
consistently.
Differential Revision: https://reviews.llvm.org/D93450
Replace the wrong code in GetRegisterSetCount() with a constant return.
The original code passed register index in place of register set index,
effectively getting always true. Correcting the code to check for
register set existence is not possible as LLDB supports only eliminating
last register sets. Just return the full number for now which should
be NFC.
Differential Revision: https://reviews.llvm.org/D93396
This reverts commit a01b26fb51, because it
breaks the "finish" command in some way -- the command does not
terminate after it steps out, but continues running the target. The
exact blast radius is not clear, but it at least affects the usage of
the "finish" command in TestGuiBasicDebug.py. The error is *not*
gui-related, as the same issue can be reproduced by running the same
steps outside of the gui.
There is some kind of a race going on, as the test fails only 20% of the
time on the buildbot.
To get LLDB one step closer to fulfil the software redundancy requirements of
modern aircrafts, we apparently decided to have two separately maintained
implementations of `CreateTypedef` in TypeSystemClang. Let's pass on the idea of
an LLDB-powered jetliner and deleted one implementation.
On a more serious note: This function got duplicated a long time ago when the
idea of CompilerType with a backing TypeSystemClang subclass happened
(56939cb310). One implementation was supposed to
be called from CompilerType::CreateTypedef and the other has just always been
around to create typedefs. By accident one of the implementations is only used
by the PDB parser while the CompilerType::CreateTypedef backend is used by the
rest of LLDB.
We also had some patches over the year that only fixed one of the two functions
(D18099 for example only fixed up the CompilerType::CreateTypedef
implementation). D51162 and D86140 both fixed the same missing `addDecl` call
for one of the two implementations.
This patch:
* deletes the `CreateTypedefType` function as its only used by the PDB parser
and the `CreateTypedef` implementation is anyway needed as it's the backend
implementation of CompilerType.
* replaces the calls in the PDB parser by just calling the CompilerType wrapper.
* moves the documentation to the remaining function.
* moves the check for empty typedef names that was only in the deleted
implementation to the other (I don't think this fixes anything as I believe
all callers are already doing the same check).
I'll fix up the usual stuff (not using StringRef, not doing early exit) in a NFC
follow-up.
This patch is not NFC as the PDB parser now calls the function that has the fix
from D18099.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D93382
Fix the POSIX-DYLD plugin to update the cached executable path after
attaching. Previously, the path was cached in DYLDRendezvous
constructor and not updated afterwards. This meant that if LLDB was
attaching to a process (e.g. via connecting to lldb-server), the code
stored the empty path before DidAttach() resolved it. The fix updates
the cached path in DidAttach().
This fixes a new instance of https://llvm.org/pr17880
Differential Revision: https://reviews.llvm.org/D92264
Explicitly consider the libraries reported on the initial rendezvous
breakpoint hit added. This is necessary on FreeBSD since the dynamic
loader issues only a single 'consistent' state rendezvous breakpoint hit
for all the libraries present in DT_NEEDED. It is also helpful on Linux
where it ensures that ld-linux is considered loaded as well
as the shared system libraries reported afterwards.
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
7ad49aec12 added a __memory subdirectory to libc++
but the code we use to find libc++ from the debug info support files wasn't
prepared to encounter unknown subdirectories within libc++. The import-std-module
tests automatically fell back to not importing the std module which caused
them to fail.
This patch removes our hardcoded exception for the 'experimental' subdirectory
and instead just ignores all subdirectories of c++/vX/ when searching the
support files.
This patch exposes the Target::CreateBreakpoint overload with the
boolean argument to move to the neareast code to the SBAPI.
This is useful when creating column breakpoints to restrict lldb's
resolution to the pointed source location, preventing it to go to the next
line.
rdar://72196842
Differential Revision: https://reviews.llvm.org/D93266
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch exposes the Target::CreateBreakpoint overload with the
boolean argument to move to the neareast code to the SBAPI.
This is useful when creating column breakpoints to restrict lldb's
resolution to the pointed source location, preventing it to go to the next
line.
rdar://72196842
Differential Revision: https://reviews.llvm.org/D93266
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Currently, the interpreter's context is not updated until a command is executed.
This has resulted in the behavior of SB-interface functions and some commands
depends on previous user actions. The interpreter's context can stay uninitialized,
point to a currently selected target, or point to one of previously selected targets.
This patch removes any usages of CommandInterpreter::UpdateExecutionContext.
CommandInterpreter::HandleCommand* functions still may override context temporarily,
but now they always restore it before exiting. CommandInterpreter saves overriden
contexts to the stack, that makes nesting commands possible.
Added test reproduces one of the issues. Without this fix, the last assertion fails
because interpreter's execution context is empty until running "target list", so,
the value of the global property was updated instead of process's local instance.
Differential Revision: https://reviews.llvm.org/D92164
TargetList::CreateTarget automatically adds created target to the list, however,
CommandObjectTargetCreate does some additional preparation after creating a target
and which can fail. The command should remove created target if it failed. Since
the function has many ways to return, scope guard does this work safely.
Changes to the TargetList make target adding and selection more transparent.
Other changes remove unnecessary SetSelectedTarget after CreateTarget.
Differential Revision: https://reviews.llvm.org/D93052
Right now we have one large AST for all types in LLDB. All ODR violations in
types we reconstruct are resolved by just letting the ASTImporter handle the
conflicts (either by merging types or somehow trying to introduce a duplicated
declaration in the AST). This works ok for the normal types we build from debug
information as most of them are just simple CXXRecordDecls or empty template
declarations.
However, with a loaded `std` C++ module we have alternative versions of pretty
much all declarations in the `std` namespace that are much more fleshed out than
the debug information declarations. They have all the information that is lost
when converting to DWARF, such as default arguments, template default arguments,
the actual uninstantiated template declarations and so on.
When we merge these C++ module types into the big scratch AST (that might
already contain debug information types) we give the ASTImporter the tricky task
of somehow creating a consistent AST out of all these declarations. Usually this
ends in a messy AST that contains a mostly broken mix of both module and debug
info declarations. The ASTImporter in LLDB is also importing types with the
MinimalImport setting, which usually means the only information we have when
merging two types is often just the name of the declaration and the information
that it contains some child declarations. This makes it pretty much impossible
to even implement a better merging logic (as the names of C++ module
declarations and debug info declarations are identical).
This patch works around this whole merging problem by separating C++ module
types from debug information types. This is done by splitting up the single
scratch AST into two: One default AST for debug information and a dedicated AST
for C++ module types.
The C++ module AST is implemented as a 'specialised AST' that lives within the
default ScratchTypeSystemClang. When we select the scratch AST we can explicitly
request that we want such a isolated sub-AST of the scratch AST. I kept the
infrastructure more general as we probably can use the same mechanism for other
features that introduce conflicting types (such as programs that are compiled
with a custom -wchar-size= option).
There are just two places where we explicitly have request the C++ module AST:
When we export persistent declarations (`$mytype`) and when we create our
persistent result variable (`$0`, `$1`, ...). There are a few formatters that
were previously assuming that there is only one scratch AST which I cleaned up
in a preparation revision here (D92757).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D92759
Prevent lldb from crashing when multiple threads are concurrently
accessing the SB API with reproducer capture enabled.
The API instrumentation records both the input arguments and the return
value, but it cannot block for the duration of the API call. Therefore
we introduce a sequence number that allows to to correlate the function
with its result and add locking to ensure those two parts are emitted
atomically.
Using the sequence number, we can detect situations where the return
value does not succeed the function call, in which case we print an
error saying that concurrency is not (currently) supported. In the
future we might attempt to be smarter and read ahead until we've found
the return value matching the current call.
Differential revision: https://reviews.llvm.org/D92820
Several data formatters assume their types are in the Target's scratch AST and
build new types from that scratch AST instance. However, types from different
ASTs shouldn't be mixed, so this (unchecked) assumption may lead to problems if
we ever have more than one scratch AST or someone somehow invokes data
formatters on a type that are not in the scratch AST.
Instead we can use in all the formatters just the TypeSystem of the type we're
formatting. That's much simpler and avoids all the headache of finding the right
TypeSystem that matches the one of the formatted type.
Right now LLDB only has one scratch TypeSystemClang instance and we format only
types that are in the scratch AST, so this doesn't change anything in the
current way LLDB works. The intention here is to allow follow up refactorings
that introduce multiple scratch ASTs with the same Target.
Differential Revision: https://reviews.llvm.org/D92757
LLDB is supposed to ask the Clang Driver what the default module cache path is
and then use that value as the default for the
`symbols.clang-modules-cache-path` setting. However, we use the property type
`String` to change `symbols.clang-modules-cache-path` even though the type of
that setting is `FileSpec`, so the setter will simply do nothing and return
`false`. We also don't check the return value of the setter, so this whole code
ends up not doing anything at all.
This changes the setter to use the correct property type and adds an assert that
we actually successfully set the default path. Also adds a test that checks that
the default value for this setting is never unset/empty path as this would
effectively disable the import-std-module feature from working by default.
Reviewed By: JDevlieghere, shafik
Differential Revision: https://reviews.llvm.org/D92772
By now LLDB can import the 'std' C++ module to improve expression evaluation,
but there are still a few problems to solve before we can do this by default.
One is that importing the C++ module is slightly slower than normal expression
evaluation (mostly because the disk access and loading the initial lookup data
is quite slow in comparison to the barebone Clang setup the rest of the LLDB
expression evaluator is usually doing). Another problem is that some complicated
types in the standard library aren't fully supported yet by the ASTImporter, so
we end up types that fail to import (which usually appears to the user as if the
type is empty or there is just no result variable).
To still allow people to adopt this mode in their daily debugging, this patch
adds a setting that allows LLDB to automatically retry failed expression with a
loaded C++ module. All success expressions will behave exactly as they would do
before this patch. Failed expressions get a another parse attempt if we find a
usable C++ module in the current execution context. This way we shouldn't have
any performance/parsing regressions in normal debugging workflows, while the
debugging workflows involving STL containers benefit from the C++ module type
info.
This setting is off by default for now with the intention to enable it by
default on macOS soon-ish.
The implementation is mostly just extracting the existing parse logic into its
own function and then calling the parse function again if the first evaluation
failed and we have a C++ module to retry the parsing with.
Reviewed By: shafik, JDevlieghere, aprantl
Differential Revision: https://reviews.llvm.org/D92784
When the architecture from the returned plist differs from the
architecture lldb will pick when loading the binary file, lldb will
reject the binary as not matching. We are working with UUID's in
this case, so an architecture is not disambiguating anything; it
just opens this possibility for failing to load the specified binary.
Stop reading the architecture from the plist.
<rdar://problem/71612561>
Differential revision: https://reviews.llvm.org/D92692
The reproducers currently use a static variable to track the API
boundary. This is obviously incorrect when the SB API is used
concurrently. While I do not plan to support that use-case (right now),
I do want to avoid us crashing. As a first step, correctly track API
boundaries across multiple threads.
Before this patch SB API calls made by the embedded script interpreter
would be considered "behind the API boundary" and correctly ignored.
After this patch, we need to tell the reproducers to ignore the
scripting thread as a "private thread".
Differential revision: https://reviews.llvm.org/D92811
LLDB is ignoring compilation errors for one-line breakpoint scripts.
This patch fixes the issues and now the error message of the
ScriptInterpreter is shown to the user.
I had to remove a new-line character for the Lua interpreter since it
was duplicated.
Differential Revision: https://reviews.llvm.org/D92729
Copy the Linux implementation of GetLoadedModuleFileSpec()
and GetFileLoadAddress() into NativeProcessFreeBSD. This does not seem
to change anything at the moment but reducing the differences between
the plugins should help us in the long term.
Differential Revision: https://reviews.llvm.org/D92314
Explicitly consider the libraries reported on the initial eTakeSnapshot
action added, through adding them to the added soentry list
in DYLDRendezvous::SaveSOEntriesFromRemote(). This is necessary
on FreeBSD since the dynamic loader issues only a single 'consistent'
state rendezvous breakpoint hit for all the libraries present
in DT_NEEDED (while Linux issues an added-consistent event pair).
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
Force gdb-remote plugin when attaching using the derivatives
of PlatformPOSIX class. This is consistent with the behavior
for launching processes (via DebugProcess() method) and guarantees
consistent plugin choice on FreeBSD.
Differential Revision: https://reviews.llvm.org/D92667
We keep referring to the single object created by this class as
'scratch AST/Context/TypeSystem' so at this point we might as well rename the
class. It's also not involved at all in expression evaluation, so the
'ForExpressions' prefix is a bit misleading.
Use the cpu subtype enum values from llvm::MachO in the ArchSpec MachO
table. As I'm already cluttering the history, restore the table's
formatting to its original glory.
Differential revision: https://reviews.llvm.org/D92601
Make sure we recognize cpu sub-type 2 as arm64. In reality it's arm64e,
but we don't have the triple for that. Without this patch, we fall back
to unknown-apple-macosx- for the default architecture, which breaks
things like running expressions without a target.
Differential revision: https://reviews.llvm.org/D92603
Extract remote debugging logic from PlatformMacOSX and move it into
PlatformRemoteMacOSX so it can benefit from all the logic necessary for
remote debugging.
Until now, remote macOS debugging was treated almost identical to local
macOS debugging. By moving in into its own class, we can have it inherit
from PlatformRemoteDarwinDevice and all the functionality it provides,
such as looking at the correct DeviceSupport directory.
rdar://68167374
Differential revision: https://reviews.llvm.org/D92452
The code that gets the ScriptInterpreter was not considering the
case that it receives a Lua interpreter.
Differential Revision: https://reviews.llvm.org/D92249
We currently reject all templates that have either zero args or that have a
parameter pack without a name. Both cases are actually allowed in C++, so
rejecting them leads to LLDB instead falling back to a dummy 'void' type. This
leads to all kind of errors later on (most notable, variables that have such
template types appear to be missing as we can't have 'void' variables and
inheriting from such a template type will cause Clang to hit some asserts when
finding that the base class is 'void').
This just removes the too strict tests and adds a few tests for this stuff (+
some combinations of these tests with preceding template parameters).
Things that I left for follow-up patches:
* All the possible interactions with template-template arguments which seem like a whole new source of possible bugs.
* Function templates which completely lack sanity checks.
* Variable templates are not implemented.
* Alias templates are not implemented too.
* The rather strange checks that just make sure that the separate list of
template arg names and values always have the same length. I believe those
ought to be asserts, but my current plan is to move both those things into a
single list that can't end up in this inconsistent state.
Reviewed By: JDevlieghere, shafik
Differential Revision: https://reviews.llvm.org/D92425
This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.
As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.
This committ also includes a test to verify all of above functionality
on Arm64.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91241
This came up while putting together our new strategy to create g/G packets
in compliance with GDB RSP protocol where register offsets are calculated in
increasing order of register numbers without any unused spacing.
RegisterInfoPOSIX_arm64::GPR size was being calculated after alignment
correction to 8 bytes which meant there was a 4 bytes unused space between
last gpr (cpsr) and first vector register V. We have put LLVM_PACKED_START
decorator on RegisterInfoPOSIX_arm64::GPR to make sure single byte
alignment is enforced. Moreover we are now doing to use arm64 user_pt_regs
struct defined in ptrace.h for accessing ptrace user registers.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92063
Both functions are effectively returning a single string literal. Change
the interface to return a llvm::StringRef instead of populating a vector
of std::strings or returning a std::string respectively.
Our type formatters/summaries match on the internal type name we generate in LLDB for Clang types.
These names were generated using Clang's default printing policy. However Clang's
default printing policy got tweaked over the last month to make the generated type
names more readable (by for example excluding inline/anonymous namespaces and
removing template arguments that have their default value). This broke the formatter
system where LLDB's matching logic now no longer can format certain types as
the new type names generated by Clang's default printing policy no longer match
the type names that LLDB/the user specified.
I already introduced LLDB's own type printing policy and fixed the inline/anonymous
namespaces in da121fff11 (just to get the
test suite passing again).
This patch is restoring the old type printing behaviour where always include the template
arguments in the internal type name (even if they match the default args). This should get
template type formatters/summaries working again in the rare situation where we do
know template default arguments within LLDB. This can only happen when either having
a template that was parsed in the expression parser or when we get type information from a C++ module.
The Clang change that removed defaulted template arguments from Clang's printing policy was
e7f3e2103c
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92311
These callbacks are set using the following:
breakpoint command add -s lua -o "print('hello world!')"
The user supplied script is executed as:
function (frame, bp_loc, ...)
<body>
end
So the local variables 'frame', 'bp_loc' and vararg are all accessible.
Any global variables declared will persist in the Lua interpreter.
A user should never hold 'frame' and 'bp_loc' in a global variable as
these userdatas are context dependent.
Differential Revision: https://reviews.llvm.org/D91508
This patch ovverides GetExpeditedRegisterSet for
NativeRegisterContextLinux_arm64 to send vector granule register in
expedited register set if SVE mode is selected.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82855
This patch adds capability to introduce a custom expedited register set
in gdb remote. Currently we send register set 0 as expedited register set
but for the case of AArch64 SVE we intend to send additional information
about SVE registers size/offset configuration which can be calculated
from vg register. Therefore we will expedited Vg register in case of
AArch64 is in SVE mode to speedup register configuration calculations.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82853
Previously we used UINT16_MAX to mean no port/no specifc
port. This leads to confusion because 65535 is a valid
port number.
Instead use an optional. If you want a specific port call
LaunchGDBServer as normal, otherwise pass an empty optional
and it will be set to the port that gets chosen.
(or left empty in the case where we fail to find a port)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92035
Previously if you did:
$ lldb-server platform --server <...> --min-gdbserver-port 12346
--max-gdbserver-port 12347
(meaning only use port 12346 for gdbservers)
Then tried to launch two gdbservers on the same connection,
the second one would return port 65535. Which is a real port
number but it actually means lldb-server didn't find one it was
allowed to use.
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1919;port:12346;#c0
<...>
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1927;port:65535;#c7
This situation should be an error even if port 65535 does happen
to be available on the current machine.
To fix this make PortMap it's own class within
GDBRemoteCommunicationServerPlatform.
This almost the same as the old typedef but for
GetNextAvailablePort() returning an llvm::Expected.
This means we have to handle not finding a port,
by returning an error packet.
Also add unit tests for this new PortMap class.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91634
This is partly in preparation for an upcoming change that can change the
order in which DeclContext lookup results are presented.
In passing, fix some obvious errors where name lookup's notion of a
"static member function" missed static member function templates, and
where its notion of "same set of declarations" was confused by the same
declarations appearing in a different order.
This patch fixes a minor typo in RegisterContextPOSIXProcessMonitor_arm64
constructor where memset target was wrongly specified as m_fpr instead of
m_gpr_arm64.
Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.
Differential Revision: https://reviews.llvm.org/D91810
Restore Linux-alike regset names for AVX/MPX registers
as TestLldbGdbServer seems to depend on them. At the same time, fix
TestRegisters to be aware that they are not available on FreeBSD
and NetBSD, at least until we figure out a better way of reporting
unsupported register sets.
Differential Revision: https://reviews.llvm.org/D91923
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE... This matches the gdb behavior.
The Shell/Register tests now rely on the new behavior, and therefore
are run on non-Darwin systems only. The Python (API) test relies
on the legacy behavior, and is run on Darwin only.
Differential Revision: https://reviews.llvm.org/D91504
Update the help string for `target.source-map` to remove the use of the word
"duple" and to add examples. Additionally I rewrote parts with the goal of
making the description more concrete.
rdar://68736012
Differential Revision: https://reviews.llvm.org/D91742
Commit f3aa9e36d9 fixed the embedded OS
build by removing all passed args for `GetName`/`GetDemangledName`. The motivation
for this was that these arguments were apparently removed in
commit 22b044877d. However, only `GetName`'s language
argument was removed but the mangling preference argument was *not* removed
(and unfortunately had a default argument). So when that commit removed all
the args it didn't just fix the build but it also changed all the mangling
preferences to 'demangled' for all `GetName` calls.
Also some `GetName` calls were outside the TARGET_OS_EMBEDDED ifdef, so
this change ended up breaking the following tests on macOS:
lldb-api :: lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
lldb-api :: lang/objc/objc-super/TestObjCSuper.py
From what I can see f3aa9e36d9 removed 12 ePreferMangled args and this patch
re-adds 12 args with roughly the same line numbers, so this *should* restore the
old behaviour and also keep the embedded build working. On the other hand,
ObjectFileMachO::ParseSymtab is a very successful attempt at writing
the longest possible function within LLVM, so this fix is partly based
on the engineering principle known as "hoping for the best".
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.
(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled
This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.
This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.
Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)
Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.
Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87442
GDBRemoteCommunicationClient::SendGetSupportedTraceType is checking whether the
response is `!response.IsNormalResponse()` and infers from that that it is an error response.
However, it could be either "unsupported" or "error". If we get an unsupported response,
the code then tries to generate an llvm::Expected from the non-error response which then asserts.
Debugserver doesn't implement `jLLDBTraceSupportedType`, so we get an unsupported response
whenever this function is called on macOS.
This fixes the TestAproposWithProcess on macOS (where the `apropos` command will query
the CommandObjectTraceStart which then sends the trace type query package).
Reviewed By: wallace, shafik
Differential Revision: https://reviews.llvm.org/D91801
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE... This matches the gdb behavior.
Differential Revision: https://reviews.llvm.org/D91504
The FXSAVE/XSAVE data can have two different layouts on x86_64. When
called as FXSAVE/XSAVE..., the Instruction Pointer and Address Pointer
registers are reported using a 16-bit segment identifier and a 32-bit
offset. When called as FXSAVE64/XSAVE64..., they are reported using
a complete 64-bit offsets instead.
LLDB has historically followed GDB and unconditionally used to assume
the 32-bit layout, with the slight modification of possibly
using a 32-bit segment register (i.e. extending the register into
the reserved 16 upper bits). When the underlying operating system used
FXSAVE64/XSAVE64..., the pointer was split into two halves,
with the upper half repored as the segment registers. While
reconstructing the full address was possible on the user end (and e.g.
the FPU register tests did that), it certainly was not the most
convenient option.
Introduce a two additional 'fip' and 'fdp' registers that overlap
with 'fiseg'/'fioff' and 'foseg'/'foff' respectively, and report
the complete 64-bit address.
Differential Revision: https://reviews.llvm.org/D91497
Depends on D90490.
The stop command is simple and invokes the new method Trace::StopTracingThread(thread).
On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation.
Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process.
As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D90729
I noticed that Process is inheriting from UserID to store its PID value. This patch
replaces this with a dedicated field in the Process class. This is NFC, but has some
small effects on the code using Process:
* `GetID()` now returns a `lldb::pid_t` like all other process code instead of `lldb::user_id_t`. Both are typedefs for `uint64_t`, so no change in behaviour.
* The equality operators defined for UserID no longer accept Process instances.
* Removes the inherited method `Process::Clear()` which didn't actually clear anything beside the PID value.
We maybe should also remove the getters/setters to `S/GetPID` or something like that. I can update all the code for that
in a follow-up NFC commit.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91699
This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send registers in a
way that their offset fields can be re-constructed based on register sizes
in the increasing order of register number.
In context to Arm64 SVE, FPCR and FPSR are same registers in FPU regset and
SVE regset. Previously FPSR/FPCR offset was set at the end of SVE data
because Linux ptrace data placed FPCR and FPSR at the end of SVE register set.
Considering interoperability with other stubs like QEMU and that g packets
should generate register data in increasing order of register numbers. We
have to move FPCR/FPSR offset up to its original location according to
register numbering scheme of ARM64 registers with SVE registers included.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90741
In our recent discussion we are aiming to make LLDB registers exchange minimum
possible information in qRegisterInfo or XMl register descriptions.
For SVE registers, Z registers are catagorized as primary registers and should
not have any infomration about any pseudo registers. All pseudo registers
should have the information on which primary register they belong to.
This patch removes invalidate_regs list from Z registers and will mitigate its
impact on SVE resize patch in a follow up update.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91057
LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).
This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.
We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:
* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.
Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.
Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.
There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:
Before:
```
#define NULL (nullptr) // injected module definition
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
```
After:
```
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
#ifndef NULL
#define NULL (nullptr) // injected module definition
#endif
```
Fixes rdar://10356912
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D82770
Create a helper GetOffsetRegSetData() method to get pointer
to the regset data accounting for the necessary offset. Establish
the offsets in the constructor and store them in the structure. This
avoids having to add new Get*Offset() methods and combines some common
code.
Differential Revision: https://reviews.llvm.org/D91411
Eliminate the remaining swith-case code for register getters,
and migrate YMM registers to regset-oriented model. Since these
registers are recombined from XMM and YMM_Hi128 XSAVE blocks, while LLDB
gdb-server protocol transmits YMM registers whole, the offset-based
model will not work here. Nevertheless, some improvement was possible.
Replace generic 'XSaveRegSet' along with sub-sets for XSAVE components
with 'YMMRegSet' (and more regsets in the future as further components
are implemented). Create a helper GetYMMSplitReg() method that obtains
pointers to the appropriate XMM and YMM_Hi128 blocks to reduce code
duplication.
Differential Revision: https://reviews.llvm.org/D91293
Use offset-based method to access x86 debug registers. This also
involves adding a test for the correctness of these offsets, and making
GetDR() method of NativeRegisterContextWatchpoint_x86 public to avoid
duplicate code.
Differential Revision: https://reviews.llvm.org/D91268
Use offset-based method to access base x87 FPU registers, using offsets
relative to the position of 'struct FPR', as determined by the location
of first register in it (fctrl). Change m_fpr to use a fixed-size array
matching FXSAVE size (512 bytes). Add unit tests for verifying
RegisterInfo offsets and sizes against the FXSAVE layout.
Differential Revision: https://reviews.llvm.org/D91248
Read and write registers from m_gpr using offsets from RegisterInfo
rather than explicit switch-case. This eliminates a lot of redundant
code, and avoids mistakes such as type mismatches seen recently (wrt
segment registers). The same logic will be extended to other register
sets in the future.
Make m_gpr an uint8_t std::array to ease accesses. Ideally, we could
avoid including <machine/reg.h> entirely in the future and instead
get the correct GPR size from Utility/RegisterContextFreeBSD_* somehow.
While at it, modify register set logic to use an explicit enum with
llvm::Optional<>, making the code cleaner and at the same time enabling
compiler warnings for unhandled sets.
Since now we're fully relying on 'struct GPR' defined
in Utility/RegisterContextFreeBSD_* being entirely in sync with
the system structure, add unit tests to verify the field offsets
and sizes.
Differential Revision: https://reviews.llvm.org/D91216
I think the check for whether the process is connected is totally bogus
in the first place, but on the off-chance that's it's not, we should
behave the same in synchronous and asynchronous mode.
I only have a crash report for this. I could reproduce it with a slightly older
lldb by running an expression that called pthread_kill, but we started making modules
for our expression JIT code, so that no longer triggers the bug. I can't think of another
good way to test it but the fix is obvious.
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.
Differential revision: https://reviews.llvm.org/D77153
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset.
Differential Revision: https://reviews.llvm.org/D91118
Fix Debug Register offsets to be specified relatively to UserArea
on FreeBSD/amd64 and FreeBSD/i386, and add them to UserArea on i386.
This fixes overlapping GPRs and DRs in gdb-remote protocol, making it
impossible to correctly get and set debug registers from the LLDB
client.
Differential Revision: https://reviews.llvm.org/D91254
This reverts commit 856fd98a17. The type formatters
use inline namespaces to find the formatter that fits the type ABI, so they
can't just ignore the inline namespaces.
The failing tests should be fixed by da121fff11 .
Commit 5f12f4ff90 made suppressing inline namespaces
when printing typenames default to true. As we're using the inline namespaces
in LLDB to construct internal type names (which need internal namespaces in them
to, for example, differentiate libc++'s std::__1::string from the std::string
from libstdc++), this broke most of the type formatting logic.
Depends on D89283.
The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type
thread trace start
to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.
Also, if the user typed
help thread trace start
We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.
I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got
$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}
On a machine without intel-pt support, I got
$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: E00;
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D90490
Copy the recent improvements from the FreeBSDRemote plugin, notably:
- moving event reporting setup into SetupTrace() helper
- adding more debug info into SIGTRAP handling
- handling user-generated (and unknown) SIGTRAP events
- adding missing error handling to the generic signal handler
- fixing attaching to processes
- switching watchpoint helpers to use llvm::Error
- minor style and formatting changes
This fixes a number of tests, mostly related to fixed attaching.
Differential Revision: https://reviews.llvm.org/D91167
Instead of having a custom error message, propagate the llvm::Error from
SystemInitializerCommon. I didn't realize we had this overload until
Pavel mentioned it in D90987 today.
Dwarf says (Section 2.5.1.1. of DWARF v5) that these operations should
push "generic" (pointer-sized) values. This was not the case for
DW_OP_const operations (which were pushing values based on the size of
arguments), nor DW_OP_litN (which were always pushing 64-bit values).
The practical effect of this that were were unable to display the values
of variables if the size of the DW_OP_const opcode was smaller than the
value of the variable it was describing. This would happen because we
would store this (small) result into a buffer and then would not be able
to read sufficient data out of it (in Value::GetValueAsData). Gcc emits
debug info like this.
Other (more subtle) effects are also possible.
The same fix should be applied to DW_OP_const[us] (leb128 versions), but
I'm not doing that right now, because that would cause us to display
wrong (truncated) values of variables on 32-bit targets (pr48087).
Differential Revision: https://reviews.llvm.org/D90840
Explicitly copy dbregs to new threads to ensure that watchpoints
are propagated properly. Fixes the test failure due to apparent kernel
race between reporting a new thread and resuming main thread execution
that makes implicit inheritance of dbregs unreliable. By copying them
explicitly, we ensure that the new thread correctly respects watchpoints
that were set after the thread was created but before it was reported.
The code is copied from the NetBSD plugin and modernized to use
llvm::Error.
Differential Revision: https://reviews.llvm.org/D91032
Fix DS/ES/FS/GS register sizes in getter/setter for FreeBSD. Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit. This fixes the failing
StandardStartupTest.TestStopReplyContainsThreadPcs lldb-server unittest.
Differential Revision: https://reviews.llvm.org/D91076
Update the SIGTRAP handler to account for the possibility of SIGTRAP
being generated by the user, i.e. not having any specific debugging
event associated with it, as well as receiving unknown SIGTRAPs. These
instances of SIGTRAP are passed to the regular signal handler.
Differential Revision: https://reviews.llvm.org/D91007
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.
The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90769
Fix DS/ES/FS/GS register sizes in getter/setter for NetBSD. Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit.
Differential Revision: https://reviews.llvm.org/D91090
During active replay, the ::Initialize call is replayed like any other
SB API call and the return value is ignored. Since we can't intercept
this, we terminate here before the uninitialized debugger inevitably
crashes.
Differential revision: https://reviews.llvm.org/D90987
I found a few cases where entries in the debug_line for a specific line of code have invalid entries (the address is outside of a code section or no section at all) and also valid entries. When this happens lldb might not set the breakpoint because the first line entry it will find in the line table might be the invalid one and since it's range is "invalid" no location is resolved. To get around this I changed the way we parse the line sequences to ignore those starting at an address under the first code segment.
Greg suggested to implement it this way so we don't need to check all sections for every line sequence.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D87172
This would be reproducible in future DWZ category of the testsuite as:
Failed Tests (1):
lldb-api :: python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
Differential Revision: https://reviews.llvm.org/D91014
Sometimes builds will fail with errors like:
```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.
Differential Revision: https://reviews.llvm.org/D90857
Depends on D89408.
This diff finally implements trace decoding!
The current interface is
$ trace load /path/to/trace/session/file.json
$ thread trace dump instructions
thread #1: tid = 3842849, total instructions = 22
[ 0] 0x40052d
[ 1] 0x40052d
...
[19] 0x400521
$ # simply enter, which is a repeat command
[20] 0x40052d
[21] 0x400529
...
This doesn't do any disassembly, which will be done in the next diff.
Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
- GetInstructionCount, which counts the number of instructions traced for a given thread
- IsTraceFailed, which returns an Error if decoding a thread failed
- ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included
Differential Revision: https://reviews.llvm.org/D89283
AFAICT, ~TargetList simply implements the default destructor, plus some
locking.
The history is murky, so I'm not sure why we do this locking. Perhaps,
at some point, it was possible to delete the same TargetList instance
from two different threads, setting up a race. If that were true, then
the locking would protect against the race.
Since TargetList is uniquely owned by Debugger (m_target_list), no such
race is possible today.
Testing: check-lldb
Differential Revision: https://reviews.llvm.org/D90895
Factor out dummy target creation from CreateTargetInternal.
This makes it impossible for dummy target creation to accidentally fail
due to too-strict checking in one of the CreateTargetInternal overloads.
Testing: check-lldb
rdar://70630655
Differential Revision: https://reviews.llvm.org/D90872
This patch changes the implementation of Lua's `print()` function to
respect `io.stdout`.
The original implementation uses `lua_writestring()` internally, which is
hardcoded to `stdout`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D90787
Remove the thread name caching code. It does not handle the possibility
of thread name changing between requests, therefore breaking
TestGdbRemoteThreadName. While technically we could cache the results
and reset the cache on resuming process, the gain from doing that
does not seem worth the effort.
Differential Revision: https://reviews.llvm.org/D90863
The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets. Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.
Revisit the method of switching plugins. Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.
Update the test status. Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure. For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.
Differential Revision: https://reviews.llvm.org/D90757
5d64574301 removes this enum value and now
all the switch statements that previously relied on handling this in the
'default' branch are causes compiler warnings due to redundant default cases.
This just removes the now unreachable code in there.
This class and it's surroundings contain a lot of shady code, but as far
as I can tell all of that code is unreachable (there is no code actually
setting the value to eValueTypeVector).
According to history this class was introduced in 2012 in
r167033/0665a0f09. At that time, the code seemed to serve some purpose,
and it had two entry points (in Value::SetContext and
ClangExpressionDeclMap::LookupDecl). The first entry point was deleted
in D17897 and the second one in r179842/44342735.
The stated purpose of the patch introducing this class was to fix
TestRegisters.py, and "expr $xmm0" in particular. Both of these things
function perfectly well these days without this class.
SBType::GetArrayElementType should return the actual type, not the
canonical type (e.g. int32_t, not the underlying int).
Added a test case to validate the new behavior. I also ran all other
tests on Linux (ninja check-lldb), they all pass.
Differential revision: https://reviews.llvm.org/D90318
This patch is a minor suggestion to not rely on the fact
that the `LUA_OK` macro is 0.
This assumption could change in future versions of the C API.
Differential Revision: https://reviews.llvm.org/D90556
Disable GetMemoryRegionInfo() in order to unbreak expression parsing.
For some reason, the presence of non-stub function causes LLDB to fail
to detect system libraries correctly. Through being unable to find
mmap() and allocate memory, this leads to expression parser being
broken.
The issue is non-trivial and it is going to require more time debugging.
On the other hand, the downsides of missing the function are minimal
(2 failing tests), and the benefit of working expression parser
justifies disabling it temporarily. Furthermore, the old FreeBSD plugin
did not implement it anyway, so it allows us to switch to the new plugin
without major regressions.
The really curious part is that the respective code in the NetBSD plugin
yields very similar results, yet does not seem to break the expression
parser.
Differential Revision: https://reviews.llvm.org/D90650
Remove the NetBSD-specific override of GetSharedLibraryInfoAddress(),
restoring the generic implementation from NativeProcessELF.
Differential Revision: https://reviews.llvm.org/D90620
Fix two bugs that caused attaching to a process in a pre-connected
lldb-server to fail. These are:
1. Prematurely reporting status in NativeProcessFreeBSD::Attach().
The SetState() call defaulted to notify the process, and LLGS tried
to send the stopped packet before the process instance was assigned
to it. While at it, add an assert for that in LLGS.
2. Duplicate call to ReinitializeThreads() (via SetupTrace()) that
overwrote the stopped status in threads. Now SetupTrace() is called
directly by NativeProcessFreeBSD::Attach() (not the Factory) in place
of ReinitializeThreads().
This fixes at least commands/process/attach/TestProcessAttach.py
and python_api/hello_world/TestHelloWorld.py.
Differential Revision: https://reviews.llvm.org/D90525
Fix process matching by name to make 'process attach -n ...' work.
The process finding code has an optimization that defers getting
the process name and executable format after the numeric (PID, UID...)
parameters are tested. However, the ProcessInstanceInfoMatch.Matches()
method has been matching process name against the incomplete process
information as well, and effectively no process ever matched.
In order to fix this, create a copy of ProcessInstanceInfoMatch, set
it to ignore process name and se this copy for the initial match.
The same fix applies to FreeBSD and NetBSD host code.
Differential Revision: https://reviews.llvm.org/D90454
Implement NativeThreadFreeBSD::GetName(). This is based
on the equivalent code in the legacy FreeBSD plugin, except it is
modernized a bit to use llvm::Optional and std::vector for data storage.
Differential Revision: https://reviews.llvm.org/D90298
This patch calls `lua_close()` on Lua dtor.
This guarantees that the Lua GC finalizers are honored, aside from the
usual internal clean up.
It also guarantees a call to the `__close` metamethod of any active
to-be-closed variable in Lua 5.4.
Since the previous `luaL_openlibs()` was a noop, because the standard
library is cached internally, I've removed it.
Differential Revision: https://reviews.llvm.org/D90557
This allows the Target to update its module list when loading a shared
module replaces an equivalent one.
A testcase is added which hits this codepath -- without the fix, the
target reports libbreakpad.so twice in its module list.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D89157
The various GetSharedModule methods have an optional out parameter for
the old module when a file has changed or been replaced, which the
Target uses to keep its module list current/correct. We've been using
a single ModuleSP to track "the" old module, and this change switches
to using a SmallVector of ModuleSP, which has a couple benefits:
- There are multiple codepaths which may discover an old module, and
this centralizes the code for how to handle multiples in one place,
in the Target code. With the single ModuleSP, each place that may
discover an old module is responsible for how it handles multiples,
and the current code is inconsistent (some code paths drop the first
old module, others drop the second).
- The API will be more natural for identifying old modules in routines
that work on sets, like ModuleList::ReplaceEquivalent (which I plan
on updating to report old module(s) in a subsequent change to fix a
bug).
I'm not convinced we can ever actually run into the case that multiple
old modules are found in the same GetOrCreateModule call, but I think
this change makes sense regardless, in light of the above.
When an old module is reported, Target::GetOrCreateModule calls
m_images.ReplaceModule, which doesn't allow multiple "old" modules; the
new code calls ReplaceModule for the first "old" module, and for any
subsequent old modules it logs the event and calls m_images.Remove.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D89156
Current user_id_t format is:
63{isDebugTypes} 62..32{dwo || 7fffffff}
31..0 {die_offset}
while current DIERef format is (I have made up the bit positions but the
field widths do match):
63{m_section==isDebugTypes} 62{m_dwo_num_valid} 61..32{m_dwo_num}
31..0 {m_die_offset}
Proposing to change user_id_t to:
63{isDebugTypes} 62{dwo_is_valid} 61..32{dwo; 0 if !valid}
31..0 {die_offset}
There is no benefit of having 31-bits wide dwo_num in user_id_t when it
gets converted to 30-bits width in DIERef.
This patch is for future DWZ patchset which extends the dwo_is_valid bit
into a 2-bit field (normal, DWO, DWZ, DWZcommon) so that both user_id_t
and DIERef can be changed then the same way.
It would be best to somehow unify user_id_t and DIERef but I do not plan
to do that. user_id_t should probably remain a number for the Python API
compatibility while there still needs to be some class with all the
methods to access it.
SymbolFileDWARF::GetDwpSymbolFile() and SymbolFileDWARF::GetDIE use
0x3fffffff for DWP but that does not clash:
formerly:
31bits32..62:0x7fffffff = normal unit / not any DWO
31bits32..62:0x3fffffff = DWP
31bits32..62:others = DWO unit number
after this patch:
bit62=0 30bits32..61:any = normal unit / not any DWO
bit62=1 30bits32..61:0x3fffffff = DWP
bit62=1 30bits32..61:others = DWO unit number
Differential Revision: https://reviews.llvm.org/D90413
SymbolFileDWARF::GetTypes was not handling dwo correctly. The fix is
simple -- adding a GetNonSkeletonUnit call -- but I've snuck in a small
refactor as well.
The intention is not to allow stop-hook commands to query the
user, so this is correct. It also works around a deadlock in
switching to the Python Session to execute python based commands
in the stop hook when the Debugger stdin is backed by a FILE *.
Differential Revision: https://reviews.llvm.org/D90332
This preprocessor define was meant to be used to conditionally include VCSVersion.inc. However, the define was always set, and it was the content of the header that was conditionally generated. Therefore HAVE_VCS_VERSION_INC should be cleaned up.
Reviewed By: gribozavr2, MaskRay
Differential Revision: https://reviews.llvm.org/D84623
We're no longer convinced that this is needed and we have no test
coverage to disprove that. Backing out of this change until we're
convinced otherwise.
Make it possible to use a relative path in command script import to the
location of the file being sourced. This allows the user to put Python
scripts next to LLDB command files and importing them without having to
specify an absolute path.
To enable this behavior pass `-c` to `command script import`. The
argument can only be used when sourcing the command from a file.
rdar://68310384
Differential revision: https://reviews.llvm.org/D89334
The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' parameter from
ConvertArgumentsForLaunchingInShell.
Replace the inline x86 watchpoint handling code with the reusable
NativeRegisterContextWatchpoint_x86. Implement watchpoint support
in NativeThreadFreeBSD and SIGTRAP handling for watchpoints.
Un-skip all concurrent_events tests as they pass with the new plugin.
Differential Revision: https://reviews.llvm.org/D90102
Displaying large packed bitfields did not work if one was accessing them
through a pointer, and he used the "->" notation ("[0]." notation is
fine). The reason for that is that implicit dereference in -> is plumbed
all the way down to ValueObjectChild::UpdateValue, where the process of
fetching the child value was forked for this flag. The bitfield
"sliding" code was implemented only for the branch which did not require
dereferencing.
This patch restructures the function to avoid this mistake. Processing
now happens in two stages.
- first the parent is dereferenced (if needed)
- then the child value is computed (this step includes sliding and is
common for both branches)
Differential Revision: https://reviews.llvm.org/D89236
Ensure that xs_xstate_bv is set correctly before calling
WriteRegisterSet(). The bit can be clear if the relevant registers
were at their initial state when they were read, and it needs to be set
in order to apply changes from the XState structure.
Differential Revision: https://reviews.llvm.org/D90105
Unify the x86 regset API to use XStateRegSet for all FPU registers,
therefore eliminating the legacy API based on FPRegSet. This makes
the code a little bit simpler but most notably, it provides future
compatibility for register caching.
Since the NetBSD kernel takes care of providing compatibility with
pre-XSAVE processors, PT_{G,S}ETXSTATE can be used on systems supporting
only FXSAVE or even plain FSAVE (and unlike PT_{G,S}ETXMMREGS, it
clearly indicates that XMM registers are not supported).
Differential Revision: https://reviews.llvm.org/D90034
As mentioned in the comment inside the code, the Intel documentation
states that the internal CPU buffer is flushed out to RAM only when tracing is
disabled. Otherwise, the buffer on RAM might be stale.
This diff disables tracing when the trace buffer is going to be read. This is a
quite safe operation, as the reading is done when the inferior is paused at a
breakpoint, so we are not losing any packets because there's no code being
executed.
After the reading is finished, tracing is enabled back.
It's a bit hard to write a test for this now, but Greg Clayton and I will
refactor the PT support and writing tests for it will be easier. However
I tested it manually by doing a script that automates
the following flow
```
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at main.cpp:4:7, address = 0x000000000040050f
(lldb) r
Process 3078226 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x000000000040050f a.out`main at main.cpp:4:7
(lldb) processor-trace start
(lldb) b 5
Breakpoint 2: where = a.out`main + 22 at main.cpp:5:12, address = 0x0000000000400516
(lldb) c
Process 3078226 resuming
Process 3078226 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x0000000000400516 a.out`main at main.cpp:5:12
(lldb) processor-trace show-instr-log
thread #1: tid=3078226
0x40050f <+15>: movl $0x0, -0x8(%rbp)
>>> Before, some runs of the script up to this point lead to empty traces
(lldb) b 6
Breakpoint 3: where = a.out`main + 42 at main.cpp:6:14, address = 0x000000000040052a
(lldb) c
Process 3092991 resuming
Process 3092991 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 3.1
frame #0: 0x000000000040052a a.out`main at main.cpp:6:14
(lldb) processor-trace show-instr-log thread #1: tid=3092991
0x40050f <+15>: movl $0x0, -0x8(%rbp)
0x400516 <+22>: movl $0x0, -0xc(%rbp)
0x40051d <+29>: cmpl $0x2710, -0xc(%rbp) ; imm = 0x2710
0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp
0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp
>>> The trace was re-enabled correctly and includes the instruction of the
first reading.
```
Those instructions correspond to these lines
```
3 int main() {
4 int z = 0;
5 for (int i = 0; i < 10000; i++) {
6 z += fun(z)
...
```
Differential Revision: https://reviews.llvm.org/D85241
For performance reasons the reproducers don't copy the files captured by
the file collector eagerly, but wait until the reproducer needs to be
generated.
This is a problematic when LLDB crashes and we have to do all this
signal-unsafe work in the signal handler. This patch uses a similar
trick to clang, which has the driver invoke a new cc1 instance to do all
this work out-of-process.
This patch moves the writing of the mapping file as well as copying over
the reproducers into a separate process spawned when lldb crashes.
Differential revision: https://reviews.llvm.org/D89600
We were returning the default constructed unique_pointer from
TypeSystem.h for which the compiler does not have a definition. Move the
implementation into the cpp file.
This patch redesigns the Target::GetUtilityFunctionForLanguage API:
- Use a unique_ptr instead of a raw pointer for the return type.
- Wrap the result in an llvm::Expected instead of using a Status object as an I/O parameter.
- Combine the action of "getting" and "installing" the UtilityFunction as they always get called together.
- Pass std::strings instead of const char* and std::move them where appropriate.
There's more room for improvement but I think this tackles the most
prevalent issues with the current API.
Differential revision: https://reviews.llvm.org/D90011
Split the current NetBSD watchpoint implementation for x86 into Utility,
and revamp it to improve readability. This code is meant to be used
as a common class for all x86 watchpoint implementation, particularly
these on FreeBSD and Linux.
The code uses global watchpoint enable bits, as required by the NetBSD
kernel. If it ever becomes necessary for any platform to use local
enable bits instead, this can be trivially abstracted out.
The code also postpones clearing DR6 until a new different watchpoint
is being set in place of the old one. This is necessary since LLDB
repeatedly reenables watchpoints on all threads, by clearing
and restoring them. When DR6 is cleared as a part of that, then pending
events on other threads can no longer be associated with watchpoints
correctly.
Differential Revision: https://reviews.llvm.org/D89874
Muhammad Omair Javaid