If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D83731
Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewers: wallace, clayborg
Reviewed By: wallace, clayborg
Subscribers: cfe-commits, aprantl, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D83731
Once we start the definition of an ObjCInterfaceDecl we won't attempt to ImportDeclContext
later on. Unlike RecordDecl case which uses DefinitionCompleter to force completeDefinition
we don't seem to have a similar mechanism for ObjCInterfaceDecl.
This fix was needed due to a bug we see in LLDB expression parsing where an initial expression
cause an ObjCInterfaceDecl to be defined and subsequent expressions during import do not call
ImportDeclContext and we can end up in a situation where ivars are imported out of order and not all ivars are imported.
Differential Revision: https://reviews.llvm.org/D83972
This patch basically moves the disambiguation code from a place where
it was complicated to implement straight to where the load command is
parsed, which has the neat side affect of actually supporting all call
sites!
rdar://problem/66011909
Differential Revision: https://reviews.llvm.org/D84480
Summary:
The resolver addresses stored in the dyld trie are relative to the base
of the __TEXT segment. This is usually 0 in a dylib, so this was never
noticed, but it is not 0 for most dylibs integrated in the shared cache.
As we started using the shared cache images recently as symbol source,
this causes LLDB to fail to resolve symbols which go through a runtime
resolver.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D84083
Summary:
Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are supposed to be ignored by the
rest of the frame recognizer code. 'frame recognizer delete' is supposed to set
that flag. 'frame recognizer clear' however actually deletes all frame
recognizers (so, it doesn't set the flag but directly deletes them from the
list).
The current implementation of this concept is pretty broken. `frame recognizer
delete` sets the flag, but it somehow thinks that the recognizer id is an index
in the recognizer list. That's not true as it's actually just a member of each
recognizer entry. So it actually just sets the `deleted` flag for a random other
recognizer. The tests for the recognizer still pass as `frame recognizer list`
is also broken and just completely ignored the `deleted` flag and lists all
recognizers. Also `frame recognizer delete` just ignores if it can't actually
delete a recognizer if the id is invalid.
I think we can simplify this whole thing by just actually deleting recognizers
instead of making sure all code is actually respecting the `deleted` flag. I
assume the intention of this was to make sure that all recognizers are getting
unique ids over the course of an LLDB session, but as `clear` is actually
deleting them and we keep recycling ids, that didn't really work to begin with.
This patch deletes the `deleted` flag and just actually deletes the stored
recognizer. Also adds the missing error message in case it find a recognizer
with a given id.
Reviewers: mib
Reviewed By: mib
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84404
The patch was reverted 27d52cd86a because of failures in
TestWeakSymbols.py. These have now been addressed in D83552.
The original commit message was:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Differential Revision: https://reviews.llvm.org/D83306
This patch fixes a test failure in TestHistoryRecall caused by the move
of the `history` subcommand to the `session` command.
This change was introduced by commit 85fbb08fa2.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch moves the `history` subcommand from the `command` to `session`
command. I think it makes more sense to have it there because as the `command`
usage suggests, it should be used to manage custom LLDB commands.
However, `history` is essentially tied to a debugging session and holds
all the commands (not specifically custom ones).
This also makes it more discoverable by adding an alias for it (mimicking
the shell builtin).
Differential Revision: https://reviews.llvm.org/D84307
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
LLVM_TARGET_ARCH is not exported by LLVM so we can't use it from
standalone builds. Default to the architecture in LLVM_HOST_TRIPLE when
no LLDB_DEFAULT_TEST_ARCH was specified.
Summary: Add printing of the output of stdout during compile errors, in
addition to stderr output.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D83425
This patch introduce a new feature that allows the users to save their
debugging session's transcript (commands + outputs) to a file.
It differs from the reproducers since it doesn't require to capture a
session preemptively and replay the reproducer file in lldb.
The user can choose the save its session manually using the session save
command or automatically by setting the interpreter.save-session-on-quit
on their init file.
To do so, the patch adds a Stream object to the CommandInterpreter that
will hold the input command from the IOHandler and the CommandReturnObject
output and error. This way, that stream object accumulates passively all
the interactions throughout the session and will save them to disk on demand.
The user can specify a file path where the session's transcript will be
saved. However, it is optional, and when it is not provided, lldb will
create a temporary file name according to the session date and time.
rdar://63347792
Differential Revision: https://reviews.llvm.org/D82155
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
registerSharedLibrariesWithTarget was setting the library path
environment variable to the process build directory, but the function is
also accepting libraries in other directories (in which case they won't
be found automatically).
This patch makes the function set the path variable correctly for these
libraries too. This enables us to remove the code for setting the path
variable in TestWeakSymbols.py, which was working only accidentally --
it was relying on the fact that
launch_info.SetEnvironmentEntries(..., append=True)
would not overwrite the path variable it has set, but that is going to
change with D83306.
Reviewers: davide, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83552
RecordInterestingDirectory was added to collect dSYM bundles and their
content. For the current working directory we only want the directory to
be part of the VFS, not necessarily its contents. This patch renames the
current method to RecordInterestingDirectoryRecursively and adds a new
one that's not recursive.
file:line:column form that we use to print out locations. Since we
print them this way it makes sense we also accept that form.
Differential Revision: https://reviews.llvm.org/D83975
Currently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.
When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don't generate further bit-fields in the AST.
Later on when we do a name lookup we don't find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don't go to the runtime to obtain the offset.
This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don't work and will be addressed in follow-up PRs.
Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.
Differential Revision: https://reviews.llvm.org/D83433
Summary:
This patch adds support for AArch64 SVE register infos description and
core file register access.
AArch64 SVE is a an optional extension of Arm v8.3-a architecture. It
has introduced 32 new vector registers Z, 16 predicate P registers and FFR
predicate register. These registers have fixed names but can dynamically
be configured to different size based on underlying OS configuration.
This patch adds register info struct that describes SVE register infos and
also provides RegisterContextPOSIXCore_arm64 routines to access SVE registers.
This patch also introduces a mechanism to configure SVE register sizes and
offsets at startup before exchanging register information across gdb-remote.
TestLinuxCore.py has been updated to include testing of SVE core files.
Reviewers: labath, clayborg, jankratochvil, jasonmolenda, rengolin
Reviewed By: labath
Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77047
Reduce sleep and time outs in GDB remote testcases to one default value
for each. Stop passing these values around and always use the default
instead.
Differential revision: https://reviews.llvm.org/D83904
Summary:
With D81784, lld has started debug info resolving relocations to
garbage-collected symbols as -1 (instead of relocation addend). For an
unaware consumer this generated sequences which seemingly wrap the
address space -- their first entry was 0xfffff, but all other entries
were low numbers.
Lldb stores line sequences concatenated into one large vector, sorted by
the first entry, and searched with std::lower_bound. This resulted in
the low-value entries being placed at the end of the vector, which
utterly confused the lower_bound algorithm, and caused it to not find a
match. (Previously, these sequences would be at the start of the vector,
and normally would contain addresses that are far smaller than any real
address we want to look up, so std::lower_bound was fine.)
This patch makes lldb ignore these kinds of sequences completely. It
does that by changing the construction algorithm from iterating over the
rows (as parsed by llvm), to iterating over the sequences. This is
important because the llvm parsed performs validity checks when
constructing the sequence array, whereas the row array contains raw
data.
Reviewers: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D83957
Summary:
Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.
This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.
This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).
Reviewers: jingham, mib
Reviewed By: jingham, mib
Subscribers: MrHate, JDevlieghere
Differential Revision: https://reviews.llvm.org/D83757
Summary:
When we try to find the executable module for our target we don't check
if we already have an executable module set. This causes that when debugging
a program that dlopens another executable, LLDB will take that other executable
as the new executable of the target (which causes that future launches of the
target will launch the dlopen'd executable instead of the original executable).
This just adds a check that we only set the executable when we haven't already
found one.
Fixes rdar://63443099
Reviewers: jasonmolenda, jingham, teemperor
Reviewed By: jasonmolenda, teemperor
Subscribers: jingham, JDevlieghere
Differential Revision: https://reviews.llvm.org/D80724
This test is hitting https://bugs.python.org/issue22393 which results in
the lit multiprocessing pool deadlocking and the reproducer job timing
out on GreenDragon.
Template specializations are not handled in many of the
TypeSystemClang methods. For example, GetNumChildren does not handle
the TemplateSpecialization type class, so template specializations
always look like empty objects.
This patch just desugars template specializations in the existing
RemoveWrappingTypes desugaring helper.
Differential Revision: https://reviews.llvm.org/D83858
Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81978
Several scripts (two copies of use_lldb_suite.py, and an __init__.py) look for use_lldb_suite_root.py by checking parent directories. If for some reason it doesn't exist, it keeps checking parent directories until it finds it.
However, this only breaks when the parent directory is None, but at least on Linux, dirname('/') == '/', so this will never be None.
This changes the lookup to stop if the dirname(lldb_root) is unchanged. This was previously fixed in 67f6d842fa, but only in one copy of this script.
Additionally, this makes the failure mode more visible -- if the root is not found, it complains loudly instead of silently failing, and having later modules that need lldb_root fail.
Differential Revision: https://reviews.llvm.org/D83840
Remove the forkSubprocess method and its bookkeeping.
TestCreateAfterAttach is the only test using the fork method and I'm not
convinced it adds enough to warrant the maintenance. Pavel suggested the
same thing in D83815.
This reverts commit 29aab9b5c7.
It seems on Windows the file name is just always "lldbsuite.test.lldbtest" for
all tests and that breaks pretty much everything. Reverting until we have
a better solution.
Summary:
Currently expect_expr will not run the expression if no target is selected. This
patch changes this behavior so that expect_expr will instead fall back to the
dummy target similar to what the `expression` command is doing. This way we
don't have to compile an empty executable to be able to use `expect_expr` (which
is a waste of resources for tests that just test generic type system features).
As a test I modernized the TestTypeOfDeclTypeExpr into a Python test +
expect_expr (as it relied on the dummy target fallback of the expression
command).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D83388
Summary:
From what I know we already have the restriction that every test in the test
suite needs to have a unique file name as that's used for generating the unique
build directory for a test. It seems there is also a restriction that every test
case class in the test suite needs to have a unique name as that's used to
generate the unique log file name for the test run.
This changes the log file format to use the basename of the test file instead so
that we only have to keep worrying about the 'unique file name' restriction from
now on.
This came up because I started naming the test classes "TestCase" (as repeating
the file name in the test class seems like redudant information that just makes
renaming tests a pain).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, abidh
Differential Revision: https://reviews.llvm.org/D83767
Summary:
Certain `NSDate` constructors return a special `NSConstantDate` class which
currently ends up being unformatted as it's not in the list of supported classes
for the NSDate formatter. This patch adds that class to the supported class list
so LLDB produces a summary for it.
One of these special constructors is `[NSDate distantPast]` which returns the
date for `0001-01-01 00:00:00 UTC`. LLDB has a special case for formatting this
date but for some reason we did hardcode the wrong summary string in that
special case. Maybe the summary string was correct back when the code was
written but it isn't correct anymore (`distantPast` isn't actually defined to be
a special date but just some 'a guaranteed temporal boundary.' so maybe someone
changed the value in the last 10 years).
If someone else is wondering why we even have this special case for
`distantPast` but not for the future. The reason seems to be that our date
formatting for really old dates is off by 24 hours. So for example, adding one
second to `distantPast` will cause LLDB to print `0000-12-30 00:00:01 UTC`
(which is 24 hours behind the expected result). So to make our code appear to be
correct it seems we just hardcoded the most common NSDate result from that time
span. I'll replace that logic with a generic solution in a probably more
invasive follow up patch.
I also took the freedom to replace the magic value `-63114076800` with some
constant + documentation. I heard there are some people that don't know from the
top of their head that there are 63114076800 seconds between 1. Jan 0001 and 1.
January 2001 in whatever calendar system NSDate is using.
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83217
Always clean up subprocesses on tear down instead of relying on the
caller to do so. This is not only less error prone but also means the
tests can be more concise.
Differential revision: https://reviews.llvm.org/D83787
Skip TestProcessConnect.py on Windows and Android (the same platforms as
TestPlatformProcessConnect.py) and mark it as a NO_DEBUG_INFO test so we
don't run all the variants.
In synchronous mode, the process connect command and its aliases should
wait for the stop event before claiming the command is complete.
Currently, the stop event is always handled asynchronously by the
debugger.
The implementation takes the same approach as Process::ResumeSynchronous
which hijacks the event and handles it on the current thread. Similarly,
after this patch, the stop event is part of the command return object,
which is the property used by the test case.
Differential revision: https://reviews.llvm.org/D83728
Original commit c60216db15.
The test can only run on Darwin because of how it was setup, so I'm
enforcing that.
Summary:
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
For some reason this works on the original author's machine, but not on my. So I'm using a safer approach of using an unstripped dynamic library to place breakpoints on. The author was placing a breakpoint on the main symbol of a stripped library and for some reason it worked on their machine, but it shouldn't have...
Offender diff: D82477
Summary: User can expand and check compile unit list for the modules that have debug info.
Reviewers: wallace, clayborg
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83072
Yifan Shen