Remove the stale LLDB-Info.plist which was only used by TestHelp.py. The
latter would try to parse the version number from the plist and use that
to verify the version in the help output. Of course this never matched
so it would fall back to matching any arbitrary version.
This patch does *not* change the real LLDB-Info.plist.in file which is
used for the LLDB Framework.
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
The scoped enum tests depend on DW_AT_enum_class which was added in
Dwarf 4.
I made part of the test conditional on the Dwarf version instead of
splitting it into a separate test and using the decorator to avoid the
overhead of setting up the test.
Add stN aliases for the FPU (stmmN) registers on MacOSX. This should
improve compatibility between MacOSX and other platforms, and partially
fix x86*-fp-write tests without having to duplicate them. Note that
the tests are currently still broken due to ftag incompatibility.
Differential Revision: https://reviews.llvm.org/D91847
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
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
The tests don't work with remote debugservers. This isn't a problem with
any particular test, but the test infrastructure itself, which is why
each of these tests has a @skipIfDarwinEmbedded decorator.
This patch replaces that with a central category-based solution. It also
moves the ad-hoc windows skipping mechanism there too.
This uses the same approach as the debug info tests to avoid needing to
explicitly spell out the two kinds of tests. I convert a handful of
tests to the new mechanism. The rest will be converted in follow-up
patches.
Nearly all of our lldb-server tests have two flavours (lldb-server and
debugserver). Each of them is tagged with an appropriate decorator, and
each of them starts with a call to a matching "init" method. The init
calls are mandatory, and it's not possible to meaningfully combine them
with a different decorator.
This patch leverages the existing decorators to also tag the tests with
the appropriate debug server tag, similar to how we do with debug info
flavours. This allows us to make the "init" calls from inside the common
setUp method.
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.
The test appears to expect the inferior to be stopped, but the custom
"attach commands" leave it in a running state.
It's unclear how this could have ever worked.
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
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
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
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
Kill (rather than detach) form the inferior if debugserver loses its
connection to lldb to prevent zombie processes.
Differential revision: https://reviews.llvm.org/D92908
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
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
The test is skipped/xfailing on all platforms, so it seems that the API
got out of sync. Fix that so it returns to a 'proper' failure
on FreeBSD.
Differential Revision: https://reviews.llvm.org/D92746
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
Now that the class does not use a thread, the name is no longer
appropriate. Rename the class to "Server" and make it a long-lived
object (instead of recreating it for every expect_gdbremote_sequence
call). The idea is to make this class a wrapper for all communication
with debug/lldb-server. This will enable some additional cleanups as we
had some duplication between socket_pump non-pump code paths.
Also squeeze in some small improvements:
- use python-level timeouts on sockets instead of the manual select
calls
- use byte arrays instead of strings when working with raw packets
Test runs log some of their output to files inside the LLDB session dir. This
session dir is shared between all tests, so all the tests have to make sure they
choose a unique file name inside that directory. We currently choose by default
`<test-class-name>-<test-method-name>` as the log file name. However, that means
that if not every test class in the test suite has a unique class name, then we
end up with a race condition as two tests will try to write to the same log
file.
I already tried in D83767 changing the format to use the test file basename
instead (which we already require to be unique for some other functionality),
but it seems the code for getting the basename didn't work on Windows.
This patch instead just changes that dotest stores the log files in the build
directory for the current test. We know that directory is unique for this test,
so no need to generate some unique file name now. Also removes all the
environment vars and parameters related to the now unused session dir.
The new log paths now look like this for a failure in 'TestCppOperators`:
```
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dwarf/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dsym/Failure.log
./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_gmodules/Failure.log
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92498
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 reverts commit cf1c774d6a.
This change caused several regressions in the gdb test suite - at least
a sample of which was due to line zero instructions making breakpoints
un-lined. I think they're worth investigating/understanding more (&
possibly addressing) before moving forward with this change.
Revert "[FastISel] NFC: Clean up unnecessary bookkeeping"
This reverts commit 3fd39d3694.
Revert "[FastISel] NFC: Remove obsolete -fast-isel-sink-local-values option"
This reverts commit a474657e30.
Revert "Remove static function unused after cf1c774."
This reverts commit dc35368ccf.
Revert "[lldb] Fix TestThreadStepOut.py after "Flush local value map on every instruction""
This reverts commit 53a14a47ee.
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
* Un-inline the test.
* Use expect_expr everywhere and also check all involved types.
* Clang-format the test sources.
* Explain what we're actually testing with the 'C' and 'D' templates.
* Split out the non-template-parameter-pack part of the test into its own small test.
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
The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl default arguments. Otherwise this is simply importing the
default arguments.
Also updates several LLDB tests that now as intended omit the default template
arguments of several std templates.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92103
Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value" area that always dominates the current insertion
point, to try to avoid materializing these values more than once
(per block).
https://reviews.llvm.org/D43093 added code to sink these local
value instructions to their first use, which has two beneficial
effects. One, it is likely to avoid some unnecessary spills and
reloads; two, it allows us to attach the debug location of the
user to the local value instruction. The latter effect can
improve the debugging experience for debuggers with a "set next
statement" feature, such as the Visual Studio debugger and PS4
debugger, because instructions to set up constants for a given
statement will be associated with the appropriate source line.
There are also some constants (primarily addresses) that could be
produced by no-op casts or GEP instructions; the main difference
from "local value" instructions is that these are values from
separate IR instructions, and therefore could have multiple users
across multiple basic blocks. D43093 avoided sinking these, even
though they were emitted to the same "local value" area as the
other instructions. The patch comment for D43093 states:
Local values may also be used by no-op casts, which adds the
register to the RegFixups table. Without reversing the RegFixups
map direction, we don't have enough information to sink these
instructions.
This patch undoes most of D43093, and instead flushes the local
value map after(*) every IR instruction, using that instruction's
debug location. This avoids sometimes incorrect locations used
previously, and emits instructions in a more natural order.
This does mean materialized values are not re-used across IR
instruction boundaries; however, only about 5% of those values
were reused in an experimental self-build of clang.
(*) Actually, just prior to the next instruction. It seems like
it would be cleaner the other way, but I was having trouble
getting that to work.
Differential Revision: https://reviews.llvm.org/D91734
Extend TestProcessConnect to cover the scenario fixed by
6c0cd5676e. This replaces
command-process-connect.test which would fail if port 4321
was open.
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
Fix qRegisterInfo tests to handle Exx error response when querying
registers that are not supported on the platform in question. This
is how FreeBSD and NetBSD platforms reporting missing registers right
now, and there certainly is value from verifying the remaining
registers.
This change fixes the test for FreeBSD but NetBSD has other regressions
that still need to be researched.
Differential Revision: https://reviews.llvm.org/D91922
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
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
D91497 changed lldb/test/Shell/Register/x86-fp-write.test and added target-x86_64 to the REQUIRES clause.
It looks this test does not pass on this platform so removing it since it one of tests failing on the
green dragon build bot.
We can handle all the types in the expression evaluator now without casting.
On Linux, we have a system header declaration that is still causing issues, so
I'm skipping the test there until I get around to fix this.
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
init_llgs_test no longer takes an argument
but these two were not updated.
Also fix some mistakes in TestAutoInstallMainExecutable
to get it passing again.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D91612
Add a parser for JSON crashlogs. The CrashLogParser now defers to either
the JSONCrashLogParser or the TextCrashLogParser. It first tries to
interpret the input as JSON, and if that fails falling back to the
textual parser.
Differential revision: https://reviews.llvm.org/D91130
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
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.
"[lldb/DataFormatters] Display null C++ pointers as nullptr" added an assumption
that the member we check for is always a nullptr, but it is actually never
initialized. That causes the test to randomly fail due to the pointer having
some random value that isn't 0.
On x86_64, when you hit a __builtin_debugtrap instruction, you
can continue past this in the debugger. This patch has debugserver
recognize the specific instruction used for __builtin_debugtrap
and advance the pc past it, so that the user can continue execution
once they've hit one of these.
In the patch discussion, we were in agreement that it would be better
to have this knowledge up in lldb instead of depending on each
stub rewriting the pc behind the debugger's back, but that's a
larger scale change for another day.
<rdar://problem/65521634>
Differential revision: https://reviews.llvm.org/D91238
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
When I added TestAbortExitCode I actually planned this to be a generic test for the
exit code functionality on POSIX systems. However due to all the different test setups we
can have I don't think this worked out. Right now the test had to be made so permissive
that it pretty much can't fail.
Just to summarize, we would need to support the following situations:
1. ToT debugserver (on macOS)
2. lldb-server (on other platforms)
3. Any old debugserver version when using the system debugserver (on macOS)
This patch is removing TestAbortExitCode and adds a ToT debugserver specific test
that checks the patch that motivated the whole exit code testing. There is already
an exit-code test for lldb-server from what I can see and 3) is pretty much untestable
as we don't know anything about the system debugserver.
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D89305
This adds `expect_var_path` to test variable paths so we no longer have to
use `frame var` and find substrs in the command output. The behaviour
is identical with `expect_expr` (and it also uses the same checking backend),
but it instead calls `GetValueForVariablePath` to evaluate the string as a variable
path.
Also rewrites a few of the tests that previously used `frame variable` to use
`expect_var_path`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90450
Add a test verifying that after the 'watchpoint' command, new values
of x86 debug registers can be read back correctly. The primary purpose
of this test is to catch broken DRn reading and help debugging it.
Differential Revision: https://reviews.llvm.org/D91264
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.
Following discussion in D91193, a change made in D88792 was not quite right.
This restores the message argument, and switches from `expect` to `runCmd`.
Differential Revision: https://reviews.llvm.org/D91206
Those two decorators have identical behaviour. This removes
`not_remote_testsuite_ready` as `skipIfRemote` seems more consistent with the
other decorator names we have
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89376
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
It seems that TestErrorMessages.test is failing on the standalone + Xcode builds
as lldb-server executable can't be found by lit's default PATH search. I assume
invoking lldb-server via a lit substitution gets this working again as
everything else is working, so that's what this patch is doing.
I had to add the lldb-server substitution as the test seems lldb-server specific
and we don't want it to default to debugserver on Darwin.
Using a substitution also seems in general like a good idea so that the commands
lit is printing on failure are using the full path to lldb-server and can be
re-run in a terminal.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91155
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
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
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
Replace the plethora of ObjC-implied 'skipUnlessDarwin' decorators
with marking tests as 'objc' category (whenever missing), and skip all
ObjC tests on non-Darwin platforms. I have used '.categories' file
wherever it was present already or all (>1) tests were relying on ObjC,
and explicit add_test_categories() where there was only one test.
Differential Revision: https://reviews.llvm.org/D91056
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
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
When LLDB Python bindings are used and stack backtraces are enabled
for logging, getMainExecutable() is called with argv0 being null.
This caused the fallback function getprogpath() (used on FreeBSD, NetBSD
and Linux) to segfault. Make it handle null executable name gracefully.
Differential Revision: https://reviews.llvm.org/D91012
TestWatchpointMultipleThreads currently accounts for two scenarios:
setting the watchpoint before a new thread starts (presumably, verifying
that it will be propagated to the new thread) and setting it after
the thread starts (presumably, verifying that a new watchpoint is set
on all threads). However, the latter test currently assumes that
the thread will be reported to the debugger before the breakpoint is
hit. This is not the case on FreeBSD and NetBSD.
On NetBSD, new threads do not inherit debug registers from their parent
threads. Instead, LLDB copies them manually after the new thread is
reported. Since the thread is actually reported after the second
breakpoint location, both tests effectively check the same behavior
(i.e. watchpoint being set before the new thread is reported).
On FreeBSD, new threads inherit debug registers and we seem to hit
an interesting race condition. While the thread is reported after
the breakpoint is hit, the kernel seems to construct it and copy
the debug register before that happens. As a result, setting
the watchpoint at the second breakpoint location modifies the debug
registers of the first thread after they have been copied to the second
thread but before the debugger is aware of it. Therefore,
the watchpoint is not propagated to the second thread and the test
fails.
Extend the test to cover all three possible scenarios: setting
watchpoint before the thread is lanched, after it is launched but before
it is guaranteed to have started and after it has actually started. Add
a second barrier to account for the last case. This should ensure that
the second assumption (i.e. that the watchpoint is set on all currently
known threads) is actually tested on FreeBSD and NetBSD.
Differential Revision: https://reviews.llvm.org/D91030
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
Use skipUnlessDarwin decorator for tests that are specific to Darwin,
instead of skipIf... for all other platforms. This should make it clear
that these tests are not supposed to work elsewhere. It will also make
these tests stop repeatedly popping up while I look for tests that could
be fixed on the platform in question.
Differential Revision: https://reviews.llvm.org/D91003
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
This test requires running under the Python we built against (which is
easy) and setting up the PYTHONPATH (which is not worth it for this
simple test).
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
Fix TestGdbRemoteThreadName to call ::pthread_setname_np instead
of ::pthread_set_name_np on FreeBSD. While technically both names
are correct, the former is preferable because of compatibility
with Linux. Furthermore, the latter requires `#include <pthread_np.h>`
that was missing causing the test to fail to compile.
Differential Revision: https://reviews.llvm.org/D90862
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
`fork` is marked as `__WATCHOS_PROHIBITED __TVOS_PROHIBITED` so the test source
which is calling fork will never compile on watchOS/tvOS. This just adds the
skip decorator for these platforms.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D89695
This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `substrs` parameter. However
this issue was found by just grepping and TestPExpect's expect function is still
accepting a single string as a value to `substrs`.
This patch adds the same sanity check that D88792 added to the PExpectTest's
implementation of `expect` and also adds a small test for it.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D89302
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 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
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.
Debug server is already launched by prep_debug_monitor_and_inferior. The
second seems to have been benign so far, but after 8cc49bec2 this test
started failing frequently on GreenDragon, and this is the only unusual
thing about it.
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 fixes an flakyness is all gdb-remote tests. These tests have been
(mildly) flaky since we started using "localhost" instead of 127.0.0.1
in the test suite. The reason is that lldb-server needs to create two
sockets (v4 and v6) to listen for localhost connections. The algorithm
it uses first tries to select a random port (bind(localhost:0)) for the
first address, and then bind the same port for the second one.
The creating of the second socket can fail as there's no guarantee that
port will be available -- it seems that the (linux) kernel tries to
choose an unused port for the first socket (I've had to create thousands
of sockets to reproduce this reliably), but this can apparantly fail
when the system is under load (and our test suite creates a _lot_ of
sockets).
The socket creationg operation is considered successful if it creates at
least one socket is created, but the test harness has no way of knowing
which one it is, so it can end up connecting to the wrong address.
I'm not aware of a way to atomically create two sockets bound to the
same port. One way to fix this would be to make lldb-server report the
address is it listening on instead of just the port. However, this would
be a breaking change and it's not clear to me that's worth it (the
algorithm works pretty well under normal circumstances).
Instead, this patch sidesteps that problem by using "reverse"
connections. This way, the test harness is responsible for creating the
listening socket so it can pass the address that it has managed to open.
It also results in much simpler code overall.
To preserve test coverage for the named pipe method, I've moved the
relevant code to a dedicated test. To avoid original problem, this test
passes raw addresses (as obtained by getaddrinfo(localhost)) instead of
"localhost".
Differential Revision: https://reviews.llvm.org/D90313
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
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
TestQuoting's different test methods all build their own test binaries but
we can just reuse the same test binary by merging all asserts into one method.
This reduces the test runtime from 8 seconds to 4 seconds on my machine.
This also removes the ability to have partial failures in this test, but given
how rarely this code is touched this seems like a fair tradeoff (and we will be
able to re-add this feature once we updated our test framework).
Some other small changes:
* Fixed that we cleanup "stdout.txt" instead of "output.txt" in the cleanup.
* Fixed some formatting issues.
* Call `build` instead of directly calling `buildDefault`.
clang supports option -fsplit-machine-functions and this test checks if the
backtraces are sane when functions are split.
With -fsplit-machine-functions, a function with profiles can get split into 2
parts, the original function containing hot code and a cold part as determined
by the profile info and the cold cutoff threshold.. The cold part gets the
".cold" suffix to disambiguate its symbol from the hot part and can be placed
arbitrarily in the address space.
This test checks if the back-trace looks correct when the cold part is executed.
Differential Revision: https://reviews.llvm.org/D90081
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
Reset registers to their 'initial' state instead of a semi-random
pattern in write tests. While the latter might have been helpful
while debugging failures (i.e. to distinguish unmodified registers
from mistakenly written zeroes), the former makes it possible to test
whether xstate_bv field is written correctly when using XSAVE.
With this change, the four relevant tests start failing on NetBSD
without D90105.
Differential Revision: https://reviews.llvm.org/D90114
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
In a new Range class was introduced to simplify and the Disassembler API
and reduce duplication. It unintentionally broke the
SBFrame::Disassemble functionality because it unconditionally converts
the number of instructions to a Range{Limit::Instructions,
num_instructions}. This is subtly different from the previous behavior,
where now we're passing a Range and assume it's valid in the callee, the
original code would propagate num_instructions and the callee would
compare the value and decided between disassembling instructions or
bytes.
Unfortunately the existing tests was not particularly strict:
disassembly = frame.Disassemble()
self.assertNotEqual(len(disassembly), 0, "Disassembly was empty.")
This would pass because without this patch we'd disassemble zero
instructions, resulting in an error:
(lldb) script print(lldb.frame.Disassemble())
error: error reading data from section __text
Differential revision: https://reviews.llvm.org/D89925
This test checks that the output of `SBTarget.GetDescription()` contains the
substrings `'a.out', 'Target', 'Module', 'Breakpoint'` in that order. This test
is currently failing on Apple simulators as apparently 'Module' can't be found
in the output after 'Target".
The reason for that is that the actual output of `SBTarget.GetDescription()` looks like this:
```
Target
Module /build/path/lldb-test-build.noindex/python_api/target/TestTargetAPI.test_get_description_dwarf/a.out
0x7ff2b6d3f990: ObjectFileMachO64, file = /build/path/lldb-test-build.noindex/python_api/target/TestTargetAPI.test_get_description
[...]
0x7ff307150000: BreakpointList with 0 Breakpoints:
<LLDB module output repeats for each loaded module>
```
Clearly the string order should be `'Target', 'Module', 'a.out', 'Breakpoint'`.
However, LLDB is also a bunch of system shared libraries (libxpc.dylib,
libobjc.A.dylib, etc.) when *not* running against a simulator, we end up
unintentionally finding the `'Target', 'Module', 'Breakpoint'` substrings in the
trailing descriptions of the system modules. When running against a simulator we
however don't load shared system libraries.
This patch just moves the substrings in the correct order to make this test pass
without having any shared library modules in the description output.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89698
The existing help text was very terse and was missing several important
options. In the new version, I add a short description of each option
and a slightly longer description of the tool as a whole.
The new option list does not include undocumented no-op options:
--debug and --verbose. It also does not include undocumented short
aliases for long options, with two exceptions: -h, because it's
well-known; and -S (--setsid), as it's used in one test. Using these
options will now produce an error. I believe that is acceptable as users
aren't generally invoking lldb-server directly, and the only way to
learn about the short aliases was by looking at the source.
Differential Revision: https://reviews.llvm.org/D89477
There were invalid DIE references which nobody used. If LLDB starts to
report invalid DIE references it would lock up (mutex lock).
These invalid DIE references are there since initial check-in by:
https://reviews.llvm.org/D83302
The test reorders the basic blocks to be dis-contiguous in the address space and checks if the back trace contains the right symbol.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D89179
When opening a minidump, we might discover that it reports a UUID for a
module that doesn't match the build ID, but rather a hash of the .text
section (according to either of two different hash functions, used by
breakpad and Facebook respectively). The current logic searches for a
module by filename only to check the hash; this change updates it to
first search by directory+filename. This is important when the
directory specified in the minidump must be interpreted relative to a
user-provided sysoort, as the leaf directory won't be in the search path
in that case.
Also add a regression test; without this change, module validation fails
because we have just the placeholder module which reports as its path
the platform path in the minidump.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D89155
XFAIL nodefaultlib.cpp on darwin - the test does not pass there
XFAIL TestGdbRemoteMemoryAllocation on windows - memory is allocated
with incorrect permissions
This patch adds support for the _M and _m gdb-remote packets, which
(de)allocate memory in the inferior. This works by "injecting" a
m(un)map syscall into the inferior. This consists of:
- finding an executable page of memory
- writing the syscall opcode to it
- setting up registers according to the os syscall convention
- single stepping over the syscall
The advantage of this approach over calling the mmap function is that
this works even in case the mmap function is buggy or unavailable. The
disadvantage is it is more platform-dependent, which is why this patch
only works on X86 (_32 and _64) right now. Adding support for other
linux architectures should be easy and consist of defining the
appropriate syscall constants. Adding support for other OSes depends on
the its ability to do a similar trick.
Differential Revision: https://reviews.llvm.org/D89124
Add a test to verify that 'register read' and 'register write' commands
work correctly in a multithreaded program, in particular that they read
or write registers for the correct thread. The tests use locking
to ensure that events are serialized and the test can execute reliably.
Differential Revision: https://reviews.llvm.org/D89248
Currently one can redefine a persistent variable and LLDB will just silently
ignore the second definition:
```
(lldb) expr int $i = 1
(lldb) expr int $i = 2
(lldb) expr $i
(int) $i = 1
```
This patch makes this an error and rejects the expression with the second
definition.
A nice follow up would be to refactor LLDB's persistent variables to not just be
a pair of type and name, but also contain some way to obtain the original
declaration and source code that declared the variable. That way we could
actually make a full diagnostic as we would get from redefining a variable twice
in the same expression.
Reviewed By: labath, shafik, JDevlieghere
Differential Revision: https://reviews.llvm.org/D89310
While debugging another bug I found out that we currently don't set any limit
for the number of diagnostics Clang emits. If a user does something that
generates a lot of errors (like including some long header file from within the
expression function), then we currently spam the LLDB output with potentially
thousands of Clang error diagnostics.
Clang sets a default limit of 20 errors, but given that LLDB is often used
interactively for small expressions I would say a limit of 5 is enough. The
limit is implemented as a setting, so if a user cares about seeing having a
million errors printed to their terminal then they can just increase the
settings value.
Reviewed By: shafik, mib
Differential Revision: https://reviews.llvm.org/D88889
This patch adds several build system targets that run the normal test suite but
against the Watch/TV/iPhone simulators.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89224
This test
On macOS, this test can instead return `status = 0 (0x00000000) Terminated due to signal 6`. This updates the `CHECK` accordingly.
Differential Revision: https://reviews.llvm.org/D89273
Depends on D88841
As per the discussion in the RFC, we'll implement both
thread trace dump [instructions | functions]
This is the first step in implementing the "instructions" dumping command.
It includes:
- A minimal ProcessTrace plugin for representing processes from a trace file. I noticed that it was a required step to mimic how core-based processes are initialized, e.g. ProcessElfCore and ProcessMinidump. I haven't had the need to create ThreadTrace yet, though. So far HistoryThread seems good enough.
- The command handling itself in CommandObjectThread, which outputs a placeholder text instead of the actual instructions. I'll do that part in the next diff.
- Tests
{F13132325}
Differential Revision: https://reviews.llvm.org/D88769
With the feedback I was getting in different diffs, I realized that splitting the parsing logic into two classes was not easy to deal with. I do see value in doing that, but I'd rather leave that as a refactor after most of the intel-pt logic is in place. Thus, I'm merging the common parser into the intel pt one, having thus only one that is fully aware of Intel PT during parsing and object creation.
Besides, based on the feedback in https://reviews.llvm.org/D88769, I'm creating a ThreadIntelPT class that will be able to orchestrate decoding of its own trace and can handle the stop events correctly.
This leaves the TraceIntelPT class as an initialization class that glues together different components. Right now it can initialize a trace session from a json file, and in the future will be able to initialize a trace session from a live process.
Besides, I'm renaming SettingsParser to SessionParser, which I think is a better name, as the json object represents a trace session of possibly many processes.
With the current set of targets, we have the following
- Trace: main interface for dealing with trace sessions
- TraceIntelPT: plugin Trace for dealing with intel pt sessions
- TraceIntelPTSessionParser: a parser of a json trace session file that can create a corresponding TraceIntelPT instance along with Targets, ProcessTraces (to be created in https://reviews.llvm.org/D88769), and ThreadIntelPT threads.
- ProcessTrace: (to be created in https://reviews.llvm.org/D88769) can handle the correct state of the traces as the user traverses the trace. I don't think there'll be a need an intel-pt specific implementation of this class.
- ThreadIntelPT: a thread implementation that can handle the decoding of its own trace file, along with keeping track of the current position the user is looking at when doing reverse debugging.
Differential Revision: https://reviews.llvm.org/D88841
The problem here is in the "sliding" code in
ValueObjectChild::UpdateValue. It modifies m_bitfield_bit_offset and
m_value to ensure the bitfield value fits the window given by the
underlying type.
However, this is broken next time UpdateValue is called, because it
updates the m_value value from the parent. However, the value cannot be
slid again because the m_bitfield_bit_offset is already modified.
It seems this can happen only under specific circumstances. One way to
trigger is is to run an expression which can be interpreted (jitting it
causes a new StackFrame and ValueObject variables to be created).
I fix this bug by modifying m_byte_offset instead of m_scalar, and
ensuring the changes are folded into m_scalar regardless of how many
times UpdateValue is called.
Differential Revision: https://reviews.llvm.org/D88992
This patch fixes a few issues seen when running `ninja check-lldb` in a Release build with VS2017:
- Some binaries couldn't be found (such as lldb-vscode.exe), because .exe wasn't appended to the file name.
- Many tests used to fail since our installed locale is in French - the OS error messages are not emitted in English.
- Our codepage being Windows-1252, python failed to decode some error messages with accentuations.
Differential Revision: https://reviews.llvm.org/D88975
Add a new FreeBSD Process plugin using client/server model. This plugin
is based on the one used by NetBSD. It currently supports a subset
of functionality for amd64. It is automatically used when spawning
lldb-server. It can also be used by lldb client by setting
FREEBSD_REMOTE_PLUGIN environment variable (to any value).
The code is capable of debugging simple single-threaded programs. It
supports general purpose, debug and FPU registers (up to XMM) of amd64,
basic signalling, software breakpoints.
Adding the support for the plugin involves removing some dead code
from FreeBSDPlatform plugin (that was not ever used because
CanDebugProcess() returned false), and replacing it with appropriate
code from NetBSD platform support.
Differential Revision: https://reviews.llvm.org/D88796
This was looking at the privateState, but it's possible that
the actual process has started up and then stopped again by the
time we get to the check, which would lead us to get out of running
the stop hooks too early.
Instead we need to track the intention of the stop hooks directly.
Differential Revision: https://reviews.llvm.org/D88753
Add preconditions to `TestBase.expect()` that catch semantically invalid calls
that happen to succeed anyway. This also fixes the broken callsites caught by
these checks.
This prevents the following incorrect calls:
1. `self.expect("lldb command", "some substr")`
2. `self.expect("lldb command", "assert message", "some substr")`
Differential Revision: https://reviews.llvm.org/D88792
This reverts commit c65627a1fe.
The test immediately after the new invalid symbol test was
failing on Windows. This was because when we called
VirtualQueryEx to get the region info for 0x0,
even if it succeeded we would call GetLastError.
Which must have picked up the last error that was set while
trying to lookup "not_an_address". Which happened to be 2.
("The system cannot find the file specified.")
To fix this only call GetLastError when we know VirtualQueryEx
has failed. (when it returns 0, which we were also checking for anyway)
Also convert memory region to an early return style
to make the logic clearer.
Reviewed By: labath, stella.stamenova
Differential Revision: https://reviews.llvm.org/D88229
Darwin seems to use stmmN instead of stN. Use a regex to accept both.
Also try to actually clear st(7).
Differential revision: https://reviews.llvm.org/D88795
Add a partial read/write tests for x87 FPU registers. This includes
reading and writing ST registers, control registers and floating-point
exception data registers (fop, fip, fdp).
The tests assume the current (roughly incorrect) behavior of reporting
the 'abridged' 8-bit ftag state as 16-bit ftag. They also assume Linux
plugin behavior of reporting fip/fdp split into halves as (fiseg, fioff)
and (foseg, fooff).
Differential Revision: https://reviews.llvm.org/D88583
This seems to fail on ubuntu 18.04.5 with Clang 9 due to:
Error output:
error: Couldn't lookup symbols:
std::__1::default_delete<int>::operator()(int) const
This test seems to randomly fail on Linux machines. It's only one part of the
test failing randomly, so let's just skip it instead of reverting the whole
patch (again).
Matt's change to the register allocator in 89baeaef2f changed where we
end up after the `finish`. Before we'd end up on line 4.
* thread #1, queue = 'com.apple.main-thread', stop reason = step out
Return value: (int) $0 = 1
frame #0: 0x0000000100003f7d a.out`main(argc=1, argv=0x00007ffeefbff630) at main.c:4:3
1 extern int func();
2
3 int main(int argc, char **argv) {
-> 4 func(); // Break here
5 func(); // Second
6 return 0;
7 }
Now, we end up on line 5.
* thread #1, queue = 'com.apple.main-thread', stop reason = step out
Return value: (int) $0 = 1
frame #0: 0x0000000100003f8d a.out`main(argc=1, argv=0x00007ffeefbff630) at main.c:5:3
2
3 int main(int argc, char **argv) {
4 func(); // Break here
-> 5 func(); // Second
6 return 0;
7 }
Given that this is not expected stable to be stable I've made the test a
bit more lenient to accept both scenarios.
Also, use the StructuredData::Dump method to print the StructuredData if there
is no plugin, rather than just returning an error.
Differential Revision: https://reviews.llvm.org/D88266
Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To clear all breakpoint for a source, specify an empty array.`
However, leaving the breakpoints field unset is also a well formed request (note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's unset, we have a couple choices:
1. Crash (current behavior)
2. Clear breakpoints
3. Return an error response that the breakpoints field is missing.
I propose we do (2) instead of (1), and treat an unset breakpoints field the same as an empty breakpoints field.
[1] https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints
Reviewed By: wallace, labath
Differential Revision: https://reviews.llvm.org/D88513
When running in an ipv6-only environment where `AF_INET` sockets are not available, many lldb tests (mostly gdb remote tests) fail because things like `127.0.0.1` don't work there.
Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback of creating `AF_INET6` sockets when `AF_INET` fails.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87333
Rather than relaying on CMake to substitute the full path to the lldb
source root, use the value set in config.lldb_src_root. This makes it
slightly easier to write a custom lit.site.cfg.py.
This reverts commit f775fe5964.
I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.
Configuring the variable in CMake isn't enought, because the build mode
can't be resolved until execution time, which requires the build mode to
be substituted by lit.
With the recent patches to the ASTImporter that improve template type importing
(D87444), most of the import-std-module tests can now finally import the
type of the STL container they are testing. This patch removes most of the casts
that were added to simplify types to something the ASTImporter can import
(for example, std::vector<int>::size_type was casted to `size_t` until now).
Also adds the missing tests that require referencing the container type (for
example simply printing the whole container) as here we couldn't use a casting
workaround.
The only casts that remain are in the forward_list tests that reference
the iterator and the stack test. Both tests are still failing to import the
respective container type correctly (or crash while trying to import).
Usually when we enter a SWIG wrapper function from Python, SWIG automatically
adds a `Py_BEGIN_ALLOW_THREADS`/`Py_END_ALLOW_THREADS` around the call to the SB
API C++ function. This will ensure that Python's GIL is released when we enter
LLDB and locked again when we return to the wrapper code.
D51569 changed this behaviour but only for the generated `__str__` wrappers. The
added `nothreadallow` disables the injection of the GIL release/re-acquire code
and the GIL is now kept locked when entering LLDB and is expected to be still
locked when returning from the LLDB implementation. The main reason for that was
that back when D51569 landed the wrapper itself created a Python string. These
days it just creates a std::string and SWIG itself takes care of getting the GIL
and creating the Python string from the std::string, so that workaround isn't
necessary anymore.
This patch just removes `nothreadallow` so that our `__str__` functions now
behave like all other wrapper functions in that they release the GIL when
calling into the SB API implementation.
The motivation here is actually to work around another potential bug in LLDB.
When one calls into the LLDB SB API while holding the GIL and that call causes
LLDB to interpret some Python script via `ScriptInterpreterPython`, then the GIL
will be unlocked when the control flow returns from the SB API. In the case of
the `__str__` wrapper this would cause that the next call to a Python function
requiring the GIL would fail (as SWIG will not try to reacquire the GIL as it
isn't aware that LLDB removed it).
The reason for this unexpected GIL release seems to be a workaround for recent
Python versions:
```
// The only case we should go further and acquire the GIL: it is unlocked.
if (PyGILState_Check())
return;
```
The early-exit here causes `InitializePythonRAII::m_was_already_initialized` to
be always false and that causes that `InitializePythonRAII`'s destructor always
directly unlocks the GIL via `PyEval_SaveThread`. I'm investigating how to
properly fix this bug in a follow up patch, but for now this straightforward
patch seems to be enough to unblock my other patches (and it also has the
benefit of removing this workaround).
The test for this is just a simple test for `std::deque` which has a synthetic
child provider implemented as a Python script. Inspecting the deque object will
cause `expect_expr` to create a string error message by calling
`str(deque_object)`. Printing the ValueObject causes the Python script for the
synthetic children to execute which then triggers the bug described above where
the GIL ends up being unlocked.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88302
When a Mach-O corefile has an LC_NOTE "main bin spec" for a
standalone binary / firmware, with only a UUID and no load
address, try to locate the binary and dSYM by UUID and if
found, load it at offset 0 for the user.
Add a test case that tests a firmware/standalone corefile
with both the "kern ver str" and "main bin spec" LC_NOTEs.
<rdar://problem/68193804>
Differential Revision: https://reviews.llvm.org/D88282
Recently https://reviews.llvm.org/D88103 introduced a nice API for
converting a JSON object into C++ types, which include nice error
messaging.
I'm using that new functioniality to perform the parsing in a much more
elegant way. As a result, the code looks simpler and more maintainable,
as we aren't parsing anymore individual fields manually.
I updated the test cases accordingly.
Differential Revision: https://reviews.llvm.org/D88264
The minidump-sysroot test I added in commit 20f84257 compares two paths
using a string comparison. This causes the Windows buildbot to fail
because of mismatched forward slashes and backslashes. Use
os.path.normcase to normalize before comparing.
When the various methods of locating the module in GetRemoteSharedModule
fail, make sure we pass the original module spec to the bail-out call to
the provided resolver function.
Also make sure we consistently use the resolved module spec from the
various success paths.
Thanks to what appears to have been an accidentally inverted condition
(commit 85967fa applied the new condition to a path where GetModuleSpec
returns false, but should have applied it when GetModuleSpec returns
true), without this fix we only pass the original module spec in the
fallback if the original spec has no uuid (or has a uuid that somehow
matches the resolved module's uuid despite the call to GetModuleSpec
failing). This manifested as a bug when processing a minidump file with
a user-provided sysroot, since in that case the resolver call was being
applied to resolved_module_spec (despite resolution failing), which did
not have the path of its file_spec set.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88099
Clang has some type sugar that only serves as a way to preserve the way a user
has typed a certain type in the source code. These types are currently not
unwrapped when we query the type name for a Clang type, which means that this
type sugar actually influences what formatters are picked for a certain type.
Currently if a user decides to reference a type by doing `::GlobalDecl Var = 3;`,
the type formatter for `GlobalDecl` will not be used (as the type sugar
around the type gives it the name `::GlobalDecl`. The same goes for other ways
to spell out a type such as `auto` etc.
With this patch most of this type sugar gets stripped when the full type name is
calculated. Typedefs are not getting desugared as that seems counterproductive.
I also don't desugar atomic types as that's technically not type sugar.
Reviewed By: jarin
Differential Revision: https://reviews.llvm.org/D87481
There was a little thinko which meant when stopped in a frame with
debug information but whose CU didn't have any global variables we
report:
no debug info for frame <N>
This patch fixes that error message to say the intended:
no global variables in current compile unit
<rdar://problem/69086361>
This is the first in a series of patches that will adds a new processor trace plug-in to LLDB.
The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality.
Processor trace information can be view in a few different ways:
- post mortem where a trace is saved off that can be viewed later in the debugger
- gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped.
This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like:
- plug-in name in LLDB
- path to trace file
- shared library load information so we can re-create a target and symbolicate the information in the trace
- any other info that the trace plug-in will need to be able to successfully parse the trace information
- cpu type
- version info
- ???
A new "trace" command was added at the top level of the LLDB commmands:
- "trace load"
- "trace dump"
I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments!
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D85705
When we fixed ImportDeclContext(...) in D71378 to make sure we complete each
FieldDecl of a RecordDecl when we are importing the definition we missed the
case where a FeildDecl was an ArrayType whose ElementType is a record.
This fix was motivated by a codegen crash during LLDB expression parsing. Since
we were not importing the definition we were crashing during layout which
required all the records be defined.
Differential Revision: https://reviews.llvm.org/D86660
Previously when <addr> in "memory region <addr>" didn't
parse correctly, we'd print an error then also ask lldb-server
for a region containing LLDB_INVALID_ADDRESS.
(lldb) memory region not_an_address
error: invalid address argument "not_an_address"...
error: Server returned invalid range
Only send the command to lldb-server if the address
parsed correctly.
(lldb) memory region not_an_address
error: invalid address argument "not_an_address"...
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87694
Make it possible to run the script command with a different language
than currently selected.
$ ./bin/lldb -l python
(lldb) script -l lua
>>> io.stdout:write("Hello, World!\n")
Hello, World!
When passing the language option and a raw command, you need to separate
the flag from the script code with --.
$ ./bin/lldb -l python
(lldb) script -l lua -- io.stdout:write("Hello, World!\n")
Hello, World!
Differential revision: https://reviews.llvm.org/D86996
qemu calls the "fp" and "lr" registers via their generic names
(x29/x30). This mismatch manifested itself as not being able to unwind
or display values of some local variables.
Jonas Devlieghere