Implements the required functions on gdb-remote so the '--include-existing' flag of process attach works correctly on Linux.
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D94672
ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.
lldb-vsdode was communicating the list of modules to the IDE with events, which in practice ended up having some drawbacks
- when debugging large targets, the number of these events were easily 10k, which polluted the messages being transmitted, which caused the following: a harder time debugging the messages, a lag after terminated the process because of these messages being processes (this could easily take several seconds). The latter was specially bad, as users were complaining about it even when they didn't check the modules view.
- these events were rarely used, as users only check the modules view when something is wrong and they try to debug things.
After getting some feedback from users, we realized that it's better to not used events but make this simply a request and is triggered by users whenever they needed.
This diff achieves that and does some small clean up in the existing code.
Differential Revision: https://reviews.llvm.org/D94033
The original patch got reverted as a dependency of cf1c774d6ace59c5adc9ab71b31e .
That patch got relanded so it's also necessary to reland this patch.
Original summary:
After cf1c774d6ace59c5adc9ab71b31e762c1be695b1, Clang seems to generate code
that is more similar to icc/Clang, so we can use the same line numbers for
all compilers in this test.
The DSYM variant of this test is failing since D94890. But as we explicitly
try to disable the DSYM generation in the makefile and build the archive on
our own, I don't see why we even need to run the DSYM version of the test.
This patch disables the generated derived versions of this test for the
different debug information containers (which includes the failing DSYM one).
Currently when LLDB has enough data in the debug information to import the `std` module,
it will just try to import it. However when debugging libraries where the sources aren't
available anymore, importing the module will generate a confusing diagnostic that
the module couldn't be built.
For the fallback mode (where we retry failed expressions with the loaded module), this
will cause the second expression to fail with a module built error instead of the
actual parsing issue in the user expression.
This patch adds checks that ensures that we at least have any source files in the found
include paths before we try to import the module. This prevents the module from being
loaded in the situation described above which means we don't emit the bogus 'can't
import module' diagnostic and also don't waste any time retrying the expression in the
fallback mode.
For the unit tests I did some refactoring as they now require a VFS with the files in it
and not just the paths. The Python test just builds a binary with a fake C++ module,
then deletes the module before debugging.
Fixes rdar://73264458
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D95096
Copy paste error, but the test still built on macOS. Weird.
It failed on debian linux with an error about -fno-limit-debug-info
not being a supported flag??? Not sure how this goof would cause
that error, but let's see if it did...
If they occurred before the constructor that used them, we would refuse to
set the breakpoint because we thought they were crossing function boundaries.
Differential Revision: https://reviews.llvm.org/D94846
This test is flakey on Windows and on failure it hangs causing the test suite to fail and future builds (on the buildbot, especially) to fail because they cannot re-write the files that are currently in use
This patch adds a new test case which depends on AArch64 SVE support and
dynamic resize capability enabled. It created two seperate threads which
have different values of sve registers and SVE vector granule at various
points during execution.
We test that LLDB is doing the size and offset updates properly for all
of the threads including the main thread and when we VG is updated using
prctl call or by 'register write vg' command the appropriate changes are
also update in register infos.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82866
The test couldn't find lldb-server as it's path was being overridden by
LLDB_DEBUGSERVER_PATH environment variable (pointing to debugserver).
This test should always use lldb-server, as it tests its platform
capabilities.
There's no need for the environment override, as lldb-server tests
should test the executable they just built, so I just remote the
override capability.
When a command option does not have a short version
(e.g. -f for --file), we use an arbitrary value in the
short_option field to mark it as invalid.
(though this value is unqiue to be used later for other
things)
We check that this short option is valid to print using
llvm::isPrint. This implicitly casts our int to char,
meaning we check the last char of any short_option value.
Since the arbitrary value we chose for these options is
some shortened hex version of the name, this returned true
even for invalid values.
Since llvm::isPrint returns true we later call std::islower
and/or std::isupper on the short_option value. (the int)
Calling these functions with something that cannot be validly
converted to unsigned char is undefined. Somehow we got/get
away with this but for me compiling with g++-9 I got a crash
for "help memory read".
The other command that uses this is "target variable" but that
didn't crash for unknown reasons.
Checking that short_option can fit into an unsigned char before
we call llvm::isPrint means we will not attempt to call islower/upper
on these options since we have no reason to print them.
This also fixes bogus short options being shown for "memory read"
and target variable.
For "target variable", before:
-e <filename> ( --file <filename> )
-b <filename> ( --shlib <filename> )
After:
--file <filename>
--shlib <filename>
(note that the bogus short options are just the bottom byte of our
arbitrary short_option value)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D94917
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
The way this test is structured right now, I set a breakpoint on
the instruction before the __builtin_trap. It hits the breakpoint,
disables the breakpoint, and instruction steps. This hits the
builtin_trap instruction which debugserver (on arm64) now advances
to the next instruction and reports that address to lldb. lldb
doesn't recognize this as a proper response to the instruction
step and continues executing until the next trap, and the test fails.
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.
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
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 a01b26fb51c710a3a8ef88cc83b0701461f5b9ab, 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
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
