The instrumentation unit tests' current implementation uses global
variables to track constructor calls for the instrumented classes during
replay. This is suboptimal because it indirectly relies on how the
reproducer instrumentation is implemented. I found out when adding
support for passive replay and the test broke because we made an extra
(temporary) copy of the instrumented objects.
Additionally, the old approach wasn't very self-explanatory. It took me
a bit of time to understand why we were expecting the number of objects
in the test.
This patch rewrites the test and uses the index-to-object-mapping to
verify the objects created during replay. You can now specify the
expected objects, in order, and whether they should be valid or not. I
find that it makes the tests much easier to understand. More
importantly, this approach is resilient to implementation detail changes
in the instrumentation.
The final function call to `test_X` is failing on aarch64-linux with SIGILL.
Function calls to previous expressions seem to just not work on aarch64-linux
but I don't see another way to test the multiple-run Fix-Its.
This patch refactors the test that the skipIf for aarch64 Linux only covers
the part of the test that was added D77214.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
D77327.
Differential Revision: https://reviews.llvm.org/D77326
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Add a small artificial delay in replay mode before exiting to ensure
that all asynchronous events have completed. This should reduce the
level of replay flakiness on some of the slower bots.
The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.
The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
for the event
- Disconnect(): close the connection. This is the only bit that needs to
be in the critical section, and this is to ensure that we don't close
the connection while the synchronizing thread is mucking with it.
Original commit message follows:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
I fixed the bug that the "log timer" has no tab command.
Original code has the only CommandObjectLogTimer class, but it is not
sufficient. Thus I divided the content of CommandObjectLog class into
CommandObjectLogEnable class, CommandObjectLogDisable class,
CommandObjectLogDump class, CommandObjectLogReset class,
CommandObjectLogIncrement class.
Reviewed by: teemperor
Differential Revision: https://reviews.llvm.org/D76906
Using the approach suggested by Pavel in D77588, this patch introduces a
new lldbconfig module that lives next to the lldb module. It makes it
possible to make the lldb module configurable before importing it. More
specifically it makes it possible to delay initializing the debugger,
which is needed for testing the reproducer.
Differential revision: https://reviews.llvm.org/D77661
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77444
Summary:
When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved, we
need to use a query similar to what CommandObjectSource::DumpLinesInSymbolContexts does, which is the logic
used by the CLI to display the source line at a given breakpoint. That's necessary because from a breakpoint
location you only have an address, which points to the original source location, not the source mapped one.
in the setBreakpoints request handler, we haven't been doing such query and we were returning the original
source location, which was breaking the UX of VSCode, as many breakpoints were being set but not displayed
in the source file next to each line. Besides, clicking the source path of a breakpoint in the breakpoints
view in the debug tab was not working for this case, as VSCode was trying to open a non-existent file, thus
showing an error to the user.
Ideally, we should do the query mentioned above to find the actual source location to respond to the IDE,
however, that query is expensive and users can have an arbitrary number of breakpoints set. As a simpler fix,
the request sent by VSCode already contains the full source path, which exists because the user set it from
the IDE itself, so we can simply reuse it instead of querying from the SB API.
I wrote a test for this, and found out that I had to move SetSourceMapFromArguments after RunInitCommands in
lldb-vscode.cpp, because an init command used in all tests is `settings clear -all`, which would clear the
source map unless specified after initCommands. And in any case, I think it makes sense to have initCommands
run before anything the debugger would do.
Reviewers: clayborg, kusmour, labath, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76968
Summary:
The buffer protocol does not allow us to just call PyBuffer_Release
and assume the buffer will still be there. Most things that implement the
buffer protocol will let us get away with that, but not all. We need
to release it at the end of the SWIG wrapper.
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77480
Discussed on lldb-dev with Pavel Labath. This doesn't work for
background processes [causes Python to be stuck forever], and it's
unclear whether it's needed. There's no test, also. If this turns
out to be useful, it can be recommitted with a functional implementation
and a test.
My main work directory is on a separate partition, but I usually access
it through a symlink in my home directory. When running the tests,
either Clang or make resolves the symlink, and the real path of the
test directory ends up in the debug information.
This confuses this test as LLDB is trying to remap the real path, but
the remapping description uses the path with the symlink in
it. Calling realpath on the source path when constructing the
remapping description fixes it.
We would return `LLDB_INVALID_IMAGE_TOKEN` for the address rather than
the correct value of `LLDB_IMAGE_ADDRESS`. This would result in the
check for the return value to silently pass on x64 as the invalid
address and invalid token are of different sizes (`size_t` vs
`uintprr_t`). This corrects the return value to `LLDB_INVALID_ADDRESS`
and addresses the rest to reset the mapped address to the invalid value.
This was found by inspection when trying to implement module support for
Windows.
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.
The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.
rdar://problem/60640017
Differential Revision: https://reviews.llvm.org/D76471
Greg Clayton a few years ago.
My patch to augment the symbol table in Mach-O files with the
dyld trie exports data structure only categorized symbols as code
or data, but Greg Clayton had a patch to do something similar to
swift a few years ago that had a more extensive categorization of
symbols, as well as extracting some objc class/ivar names from the
entries. This patch is basically just Greg's, updated a bit and
with a test case added to it.
<rdar://problem/50791451>
Differential Revision: https://reviews.llvm.org/D77369
This patch adds parts of the stack that should be useful for unwinding
to the jThreadsInfo reply from lldb-server. We return the top of the
stack (12 words), and we also try to walk the frame pointer linked list
and return the memory containing frame pointer and return address pairs.
The idea is to cover the cases with and without frame pointer omission.
Differential Revision: https://reviews.llvm.org/D74398
Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.
This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).
The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.
Reviewers: jingham, JDevlieghere, friss, shafik
Reviewed By: shafik
Subscribers: shafik, abidh
Differential Revision: https://reviews.llvm.org/D77214
Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error". Fix-Its connected to warnings and other severities are supposed to
be ignored as LLDB doesn't seem to trust Clang Fix-Its in these situations.
However, LLDB also ignores all Fix-Its coming from "note:" diagnostics. These diagnostics
are usually emitted alongside other diagnostics (both warnings and errors), either to keep
a single diagnostic message shorter or because the Fix-It is in a different source line. As they
are technically their own (non-error) diagnostics, we currently are ignoring all Fix-Its associated with them.
For example, this is a possible Clang diagnostic with a Fix-It that is currently ignored:
```
error: <user expression 1>:2:10: too many arguments provided to function-like macro invocation
ToStr(0, {,})
^
<user expression 1>:1:9: macro 'ToStr' defined here
#define ToStr(x) #x
^
<user expression 1>:2:1: cannot use initializer list at the beginning of a macro argument
ToStr(0, {,})
^ ~~~~
```
We also don't store "note:" diagnostics at all, as LLDB's abstraction around the whole diagnostic
concept doesn't have such a concept. The text of "note:" diagnostics is instead
appended to the last non-note diagnostic (which is causing that there is no "note:" text in the
diagnostic above, as all the "note:" diagnostics have been appended to the first "error: ..." text).
This patch fixes the ignored Fix-Its in note-diagnostics by appending them to the last non-note
diagnostic, similar to the way we handle the text in these diagnostics.
Reviewers: JDevlieghere, jingham
Reviewed By: JDevlieghere
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D77055
This is a preparation for an upcoming patch which adds support for
DWARFv5 unit index sections. The patch adds tag "_EXT_" to identifiers
which reference sections that are deprecated in the DWARFv5 standard.
See D75929 for the discussion.
Differential Revision: https://reviews.llvm.org/D77141
Mark it expected fail for now.
The test output shows that the "internal" thread listing isn't showing the
step out plan that we use to step back out of a function we're stepping into.
The internal plan listing code has nothing platform specific in it, so that
isn't the problem.
I am pretty sure the difference is that on MacOS we step into the function and then need to
step back out again so we push the internal plan the test is checking for. But on Linux we
are able to step past the function without stepping into it.
So nothing is actually going wrong here, I just need to find a better test case where I
can ensure we are going to have to push a private plan. It's probably better to test this
using a custom thread plan, then I can control the state of the plan stack better.
That's for Monday...
Summary:
A recent change in ThreadPlans introduced this little compilation error.
Seems to be related to the work around https://reviews.llvm.org/D76814.
Reviewers: clayborg, labath, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77450
Summary:
In this diff of mine D77186 I introduce a bug in the replace operation, where I was failing fast by mistake.
Besides, a similar problem existed in the insert-after operation, where it was failing fast.
Finally, the remove operation was wrong, as it was not using the indices provided by the users.
I fixed those issues and added some tests account for cases with multiple elements in these requests.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77324
Summary:
@labath mentioned to me that test files shouldn't have a license header.
I saw this one some days ago, so I'm doing some cleaning.
Reviewers: labath, clayborg
Subscribers: lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77328
Also turn on the command trace unconditionally for TestThreadPlanCommands.py as the
tests for the Ubuntu bot don't seem to run with -t making it hard to see why this is
failing remotely.
Apparently the intention was to copy the condition above:
if (types.GetSize() >= max_matches)
break;
So that if the iteration stopped because of too many matches we do not
add even more matches in this 'Clang modules' block downward.
It was implemented by:
SymbolFileDWARF: Unconditionally scan through clang modules. NFCish
fe9eaadd68
Differential Revision: https://reviews.llvm.org/D77336
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.
Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.
Differential Revision: https://reviews.llvm.org/D76814
It is an obvious part of D77326.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
in D77327.
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.
This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.
Differential revision: https://reviews.llvm.org/D77351
This reimplements Symbols::FindSymbolFileInBundle to use the VFS-aware
recursive directory iterator. This is needed for reproducer replay.
Differential revision: https://reviews.llvm.org/D77337
The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.
Differential revision: https://reviews.llvm.org/D77302
Summary: The IDE has no packets that are sent to lldb-vscode that say which thread and frame are selected. The only way we know is we get a request for variables for a stack frame via a "scopes" request. When we receive this packet we make that thread and frame the selected thread and frame in lldb. This way when people execute lldb commands in the debug console by prefixing the expression with the backtick character, we will have the right thread and frame selected. Previously this was not updated as new stack frames were selected.
Reviewers: labath, aadsm, wallace, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77347
* This is a reattempted commit due to a previous builtbot failure
- Now using a env var to determine whether to run the test, as
someone might have built liblldbIntelFeatures.so without intelPT
support, which would make this test fail.
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
--script-language python and --script-language lua are both valid now.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77241
This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.
The original commit message was:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Differential Revision: https://reviews.llvm.org/D76835
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Previously, this was reverted in bf65f19b becuase it checked whether
TARGET_OS_EMBEDDED is defined, but that macro is always defined.
Update the condition to check that TARGET_OS_OSX is true.
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
Summary:
Depends on D76872.
There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.
The test is skipped if the Intel PT plugin library is not built.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77107
Summary:
Several lldb-vscode users have noticed that when a source map rule is invalid (because a folder doesn't exist anymore), the rest of the source maps from their configurations are not applied.
This happens because lldb-vscode executes a single "settings set target.source-map" command with all the source maps and LLDB processes them one by one until one fails.
Instead of doing this, we can process in LLDB all the source map rules and apply the valid ones instead of failing fast.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77186
The RuntimeFunction struct, which PECallFrameInfo interprets, has a
different layout and differnet semantics on all architectures.
Differential Revision: https://reviews.llvm.org/D77000
Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.
Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment. This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.
Reviewers: jingham, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77123
Summary:
If we don't have a current frame then we can still run many expressions
as long as we have an active target. With this patch `expect_expr` directly
calls the target's EvaluateExpression function when there is no current frame.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77197
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
Summary:
//reviews.llvm.org/D33035 added in 2017 basic support for intel-pt. I
plan to improve it and use it to support reverse debugging.
I fixed a couple of issues and now this plugin works again:
1. pythonlib needed to be linked against it for the SB framework.
Linking was failing because of this
2. the decoding functionality was broken because it lacked handling for
instruction events. It seems old versions of libipt, the actual decoding
library, didn't require these, but modern version require it (you can
read more here
https://github.com/intel/libipt/blob/master/doc/howto_libipt.md). These
events signal overflows of the internal PT buffer in the CPU,
enable/disable events of tracing, async cpu events, interrupts, etc.
I ended up refactoring a little bit the code to reduce code duplication.
In another diff I'll implement some basic tests.
This is a simple execution of the library:
(lldb) target create "/data/users/wallace/rr-project/a.out"
Current executable set to '/data/users/wallace/rr-project/a.out' (x86_64).
(lldb) plugin load liblldbIntelFeatures.so
(lldb) b main
Breakpoint 1: where = a.out`main + 8 at test.cpp:10, address = 0x00000000004007fa
(lldb) b test.cpp:14
Breakpoint 2: where = a.out`main + 50 at test.cpp:14, address = 0x0000000000400824
(lldb) r
Process 902754 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00000000004007fa a.out`main at test.cpp:10
7 }
8
9 int main() {
-> 10 int z = 0;
11 for(int i = 0; i < 10000; i++)
12 z += fun(z);
13
Process 902754 launched: '/data/users/wallace/rr-project/a.out' (x86_64)
(lldb) processor-trace start all
(lldb) c
Process 902754 resuming
Process 902754 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x0000000000400824 a.out`main at test.cpp:14
11 for(int i = 0; i < 10000; i++)
12 z += fun(z);
13
-> 14 cout << z<< endl;
15 return 0;
16 }
(lldb) processor-trace show-instr-log
thread #1: tid=902754
0x7ffff72299b9 <+9>: addq $0x8, %rsp
0x7ffff72299bd <+13>: retq
0x4007ed <+16>: addl $0x1, %eax
0x4007f0 <+19>: leave
0x4007f1 <+20>: retq
0x400814 <+34>: addl %eax, -0x4(%rbp)
0x400817 <+37>: addl $0x1, -0x8(%rbp)
0x40081b <+41>: cmpl $0x270f, -0x8(%rbp) ; imm = 0x270F
0x400822 <+48>: jle 0x40080a ; <+24> at test.cpp:12
0x400822 <+48>: jle 0x40080a ; <+24> at test.cpp:12
```
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76872
SBPlatform::GetHostPlatform was missing the reproducer instrumentation
macros. Fixed by running lldb-instr on SBPlatform.cpp:
$ ./bin/lldb-instr ../llvm-project/lldb/source/API/SBPlatform.cpp
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
rdar://60512489
Differential Revision: https://reviews.llvm.org/D77108
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].
Differential Revision: https://reviews.llvm.org/D74023
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
In order to run check-lldb-* we need the correct map_config directives
in llvm-lit. For the standalone build, LLVM doesn't know about LLDB, and
the lldb mappings are missing. In that case we build our own llvm-lit,
and tell LLVM to use the llvm-lit in the lldb build directory.
Differential revision: https://reviews.llvm.org/D76945
This reverts commit because of test failures in TestHelloWorld.
It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.
The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.
Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76835
Summary:
D73024 seems to have fixed one set crash, but it introduced another.
Namely, if a class contains a covariant method returning itself, the
logic in MaybeCompleteReturnType could cause us to attempt a recursive
import, which would result in an assertion failure in
clang::DeclContext::removeDecl.
For some reason, this only manifested itself if the class contained at
least two member variables, and the class itself was imported as a
result of a recursive covariant import.
This patch fixes the crash by not attempting to import classes which are
already completed in MaybeCompleteReturnType. However, it's not clear to
me if this is the right fix, or if this should be handled automatically
by functions lower in the stack.
Reviewers: teemperor, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76840
LLDB only automatically applies Fix-Its from errors, but not from warnings.
Currently we only store Fix-Its from errors and then later apply all Fix-Its
we stored. This moves the filter to the application phase, so that we now
store *all* Fix-Its but only apply Fix-Its from errors later on.
This is NFC preparation for an upcoming patch.
Commit 83c81c0a46 enabled Fix-Its for top-level
expressions which change the error message of this test here as Clang comes
up with a strange Fix-It for this expression. This patch just changes the
test to declare a void variable so that Clang doesn't see a way to
recover with a Fix-It and change the error message.
Summary:
Currently top-level expressions won't automatically get Fix-Its applied. The reason
for that is that we only set the `m_fixed_text` member if we have a wrapping
source code (I.e. `m_source_code` is not zero and is wrapping some expressions).
This patch just always sets `m_fixed_text` to get this working.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77042
In ObjectFileMachO we construct the symbol table from multiple
sources -- primarily the binary's nlist records, but when the nlist
symbols have been stripped, we would augment those with function
start address from the LC_FUNCTION_STARTS or eh_frame. This patch
adds another source of symbols - the exported symbols that the
dynamic linker, dyld, uses at runtime from its trie structure. This
provides us names and addresses for these functions/data.
This patch removes the code from ParseSymtab that would reject an
empty symbol table / nlist source. It adds a new symbols_added
set which tracks the address of every symbol we've added to the
symtab. We add symbols in most-information-ful order, and before
adding a symbol from less-informational-ful source (e.g.
LC_FUNCTION_STARTS with no function name), we check if that symbol
has already been added.
On targets with thumb code generation, instead of using the 0th bit
in these addresses in FunctionStarts (or now the trie entries), we
use the data field of FunctionStarts (formerly used to track if the
func_start should be added) and a flag for the trie entries to
encode this, and only store the actual addresses in the symbols_seen
and these vectors.
<rdar://problem/50791451>
Differential revision: https://reviews.llvm.org/D76758
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.
Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.
It uses clang::Lexer which will tokenize operator<<A::B> into:
tok::kw_operator
tok::lessless
tok::raw_identifier
Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.
Differential Revision: https://reviews.llvm.org/D76168
GetDeveloperDirectory returns a const char* which is NULL when we cannot
find the developer directory. This crashes in
PlatformDarwinKernel::CollectKextAndKernelDirectories because we're
unconditionally assigning it to a std::string. Coincidentally I just
refactored a bunch of code in PlatformMacOSX so instead of a ad-hoc fix
I've reimplemented the method based on GetXcodeContentsDirectory.
The change is mostly NFC. Obviously it fixes the crash, but it also
removes support for finding the Xcode directory through he legacy
$XCODE_SELECT_PREFIX_DIR/usr/share/xcode-select/xcode_dir_path.
Differential revision: https://reviews.llvm.org/D76938
When parsing DWARF and laying out bit-fields we currently don't take into account whether we have a base class or not.
Currently if the first field is a bit-field but the bit offset is due a field we inherit from a base class we currently
treat it as an unnamed bit-field and therefore add an extra field.
This fix will not check if we have a base class and assume that this offset is due to members we are inheriting from the base.
We are currently seeing asserts during codegen when debugging clang::DiagnosticOptions.
This assumption will fail in the case where the first field in the derived class in an unnamed bit-field. Fixing the first field
being an unnamed bit-field looks like it will require a larger change since we will need a way to track or discover the last field offset of the bases(s).
Differential Revision: https://reviews.llvm.org/D76808
Summary:
The DAP specifies the following for the SetBreakpoints request:
The breakpoints returned are in the same order as the elements of the 'breakpoints' arguments
This was not followed, as lldb-vscode was returning the breakpoints in a different order, because they were first stored into a map, and then traversed. Of course, maps normally don't preserve ordering.
See this log I captured:
-->
{"command":"setBreakpoints",
"arguments":{
"source":{
"name":"main.cpp",
"path":"/Users/wallace/fbsource/xplat/sand/test-projects/buck-cpp/main.cpp"
},
"lines":[6,10,11],
"breakpoints":[{"line":6},{"line":10},{"line":11}],
"sourceModified":false
},
"type":"request",
"seq":3
}
<--
{"body":{
"breakpoints":[
{"id":1, "line":11,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true},
{"id":2,"line":6,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true},
{"id":3,"line":10,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true}]},
"command":"setBreakpoints",
"request_seq":3,
"seq":0,
"success":true,
"type":"response"
}
As you can see, the order was not respected. This was causing the IDE not to be able to disable/enable breakpoints by clicking on them in the breakpoint view in the lower corner of the Debug tab.
This diff fixes the ordering problem. The traversal + querying was done very fast in O(nlogn) time. I'm keeping the same complexity.
I also updated a couple of tests to account for the ordering.
Reviewers: clayborg, aadsm, kusmour, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76891
For multi-generator builds like MSVC and Xcode, the install source and
destination of the lldb-python-scripts target contains configuration
dependent paths and therefore need to be substituted.
Differential revision: https://reviews.llvm.org/D76827
Those fields inside of the global variable can be local variables because
they are used in only inside of one function: request_launch for launch_info
and request_attach for attach_info.
To avoid confusion an already existing local variable attach_info of
request_attach has been renamed to better reflect its purpose.
Differential Revision: https://reviews.llvm.org/D76593
In breakpad, only x86 (and mips) registers have a leading '$' in their
names. Arm architectures use plain register names.
Previously, lldb was assuming all registers have a '$'. Fix the code to
match the (unfortunately, inconsistent) reality.
Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601🔢...:0213]:5555, and the UriParser
can handle this format.
However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.
Test: BracketedHostnameWithPortIPv6 covers the case mentioned above
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: kwk, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76736
The reason is to add .yaml as a valid test suffix. The test folder
contains one yaml file, which wasn't being run because of that.
Unsurprisingly the test fails, but this was not because the underlying
functionality was broken, but rather because the test was setup
incorrectly (most likely due to overly aggressive simplification of the
test data on my part).
Therefore this patch also tweaks the test inputs in order to test what
they are supposed to test, and also updates some other breakpad tests
(because they depend on the same inputs as this one) to be more
realistic -- specifically it avoids putting symbols to the first page of
the module, as that's where normally the COFF header would reside.
lldbassert is the macro that takes care of passing along line/file/function
to the lldb_assert function. Let's call that instead of manually calling the
function.
Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.
---
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
Currently we only log in debug builds but I don't see why we would do this as this is neither
expensive and seems useful.
I looked into the git history of this code and it seems originally there was also an assert here
and the logging here was the #else branch branch for non-Debug builds.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76698
This reverts commit 6905394d15. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
// CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
^
<stdin>:3:2: note: scanning from here
frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]
Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:
```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```
This just always increments those two counters independent of build mode.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76687
Summary:
Dumping the frame using the user-set format could cause that a debug LLDB doesn't behave as a release LLDB,
which could potentially break replaying a reproducer.
Also it's kinda strange that the frame format set by the user is used in the internal log output.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76685
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
This seems only useful for debugging and it's just plainly printf'ing to the console instead
of some log, so let's remove this.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76699
Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.
Differential revision: https://reviews.llvm.org/D76626
Summary:
Detection of C strings does not work well for pointers. If the value object holding a (char*) pointer does not have an address (e.g., if it is a temp), the value is not considered a C string and its formatting is left to DumpDataExtractor rather than the special handling in ValueObject::DumpPrintableRepresentation. This leads to inconsistent outputs, e.g., in escaping non-ASCII characters. See the test for an example; the second test expectation is not met (without this patch). With this patch, the C string detection only insists that the pointer value is valid. The patch makes the code consistent with how the pointer is obtained in ValueObject::ReadPointedString.
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76650
Summary:
The default behavior of Platform::PutFile is to open the file and
truncate it if it already exists. This works fine and is a sensible
default, but it interacts badly with code-signing on iOS, as doing so
invalidates the signature of the file (even if the new content has a
valid code signature).
We have a couple tests which on purpose reload a different binary with
the same name. Those tests are currently broken because of the above
interaction.
This patch simply makes the Darwin platform unconditionally delete the
destination file before sending the new one to work around this issue.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76450
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not. It
got broken when the PersistentExpressionState was refactored.
This fixes the issue and provides a test of the behavior.
Differential Revision: https://reviews.llvm.org/D76532
This adds a formatter for libc++ std::unique_ptr.
I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.
Differential Revision: https://reviews.llvm.org/D76476
The newly introduced tests for unsetting environment variables
is failing on Windows. Skip the test there to allow investigation.
It seems like setting inherit-env to false was never tested
before. Could it be that the Windows process launcher doesn't
honor this setting?
Summary:
The interactions between the environment settings (`target.env-vars`,
`target.inherit-env`) and the inferior life-cycle are non-obvious
today. For example, if `target.inherit-env` is set, the `target.env-vars`
setting will be augmented with the contents of the host environment
the first time the launch environment is queried (usually at
launch). After that point, toggling `target.inherit-env` will have no
effect as there's no tracking of what comes from the host and what is
a user setting.
This patch computes the environment every time it is queried rather
than updating the contents of the `target.env-vars` property. This
means that toggling the `target.inherit-env` property later will now
have the intended effect.
This patch also adds a `target.unset-env-vars` settings that one can
use to remove variables from the launch environment. Using this, you
can inherit all but a few of the host environment.
The way the launch environment is constructed is:
1/ if `target.inherit-env` is set, then read the host environment
into the launch environment.
2/ Remove for the environment the variables listed in
`target.unset-env`.
3/ Augment the launch environment with the contents of
`target.env-vars`. This overrides any common values with the host
environment.
The one functional difference here that could be seen as a regression
is that `target.env-vars` will not contain the inferior environment
after launch. The patch implements a better alternative in the
`target show-launch-environment` command which will return the
environment computed through the above rules.
Reviewers: labath, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76470
Summary:
When no arguments or environment is provided to SBTarget::LaunchSimple,
make it use the values surrently set in the target properties. You can
get the current behavior back by passing an empty array instead.
It seems like using the target defaults is a much more intuitive
behavior for those APIs. It's unllikely that anyone passed NULL/None to
this API after having set properties in order to explicitely ignore them.
One direct application of this change is within the testsuite. We have
plenty of tests calling LaunchSimple and passing None as environment.
If you passed --inferior-env to dotest.py to, for example, set
(DY)LD_LIBRARY_PATH, it wouldn't be taken into account.
Reviewers: jingham, labath, #libc_abi!
Subscribers: libcxx-commits, lldb-commits
Tags: #lldb, #libc_abi
Differential Revision: https://reviews.llvm.org/D76045
Summary:
The TargetProperties constructor invokes a series of callbacks to
prime the properties from the default ones. The one callback in
charge of updating the inferior environment was commented out
because it crashed.
The reason for the crash is that TargetProperties is a parent class
of Target and the callbacks were invoked using a Target that was
not fully initialized. This patch moves the initial callback
invocations to a separate function that can be called at the end
the Target constructor, thus preventing the crash.
One existing test had to be modified, because the initialization of
the environment properties now take place at the time the target is
created, not at the first use of the environment (usually launch
time).
The added test checks that the LaunchInfo object returned by
the target has been primed with the values from the settings.
Reviewers: jingham, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76009
Summary:
LLDB keeps statistics of how many expression evaluations are 'successful' and 'failed'
which are updated after each expression evaluation (assuming statistics are enabled).
From what I understand the idea is that this could be used to define how well LLDB's
expression evaluator is working.
Currently all expressions are considered successful unless the user passes an explicit
positive element counting to the expression command (with the `-Z` flag) and then passes
an expression that successfully evaluates to a type that doesn't support element counting.
Expressions that fail to parse, execute or any other outcome are considered successful
at the moment which means we nearly always have a 100% expression evaluation
success rate.
This patch makes that expressions that fail to parse or execute to count as failed
expressions.
We can't know whether the expression failed because of an user error
of because LLDB couldn't correctly parse/compile it, but I would argue that this is
still an improvement. Assuming that the percentage of valid user expressions stays
mostly constant over time (which seems like a reasonable assumption), then this
way we can still see if we are doing relatively better/worse from release to release.
Reviewers: davide, aprantl, JDevlieghere
Reviewed By: aprantl
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D76280
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Summary:
If no custom launching is used, lldb-vscode launches a program with an empty environment by default. In some scenarios, the user might want to simply use the same environment as the IDE to have a set of working environment variables (e.g. PATH wouldn't be empty). In fact, most DAPs in VSCode have this behavior by default. In other cases the user definitely needs to set their custom environment, which is already supported. To make the first case easier for the user (e.g. not having to copy the PATH to the launch.json every time they want to debug simple programs that rely on PATH), a new option is now offered. inheritEnvironment will launch the program copying its own environment, and it's just a boolean flag.
{F11347695}
Reviewers: clayborg, aadsm, diazhector98, kusmour
Subscribers: labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74636
Summary:
https://reviews.llvm.org/D65363 introduced the launchCommands argument. However, it did not add
a corresponding definition in the package.json
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76529
The fourth field in the property struct is the default unsigned or enum
value for all types, except for Array and Dictionary types. For those,
it is the element type. During the tablegen conversion, this was
incorrectly translated to DefaultValueUnsigned with a value
corresponding to the OptionValue: enum type. So for
OptionValue::eTypeString this became DefaultUnsignedValue<16>. This
patch extends the tablegen backend to understand ElementType to express
this as ElementType<"String">.
Differential revision: https://reviews.llvm.org/D76535
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Summary:
On Linux, when executing lldb-vscode on a remote machine, lldb-vscode doesn't die after the debug session ends. It keeps trying to read JSON input to no avail.
This diff indicates lldb-vscode to stop reading after a termination event has been processed.
Reviewers: clayborg, aadsm, kusmour
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76314
If LLDB attaches to an already running target, then structure SBAttachInfo is
used instead of SBLaunchInfo. lldb-vscode function request_attach sets some
values to g_vsc.launch_info, however this field is then not passed anywhere, so
this action has no effect. This commit removes invocation of
SBLaunchInfo::SetDetachOnError, which has no equivalent in SBAttachInfo.
File package.json doesn't describe detachOnError property for "attach" request
type, therefore it is not needed to update it.
Differential Revision: https://reviews.llvm.org/D76351
Summary:
This patch improves step over performance for the case when we are
stepping over a call with a next-branch-breakpoint (see
https://reviews.llvm.org/D58678), and we encounter a stop during the
call. Currently, this causes the thread plan to step-out //each frame//
until it reaches the step-over range. This is a regression introduced by
https://reviews.llvm.org/D58678 (which did improve other things!). Prior
to that change, the step-over plan would always step-out just once.
With this patch, if we find ourselves stopped in a deeper stack frame
and we already have a next branch breakpoint, we simply return from the
step-over plan's ShouldStop handler without pushing the step out plan.
In my experiments this improved the time of stepping over a call that
loads 12 dlls from 14s to 5s. This was in remote debugging scenario with
10ms RTT, the call in question was Vulkan initialization
(vkCreateInstance), which loads various driver dlls. Loading those dlls
must stop on the rendezvous breakpoint, causing the perf problem
described above.
Reviewers: clayborg, labath, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76216
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix
the Debian tests).
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
Currently when an expression fails to parse and we have a FixIt, we keep
the failed UserExpression around while trying to parse the expression with
applied fixits. This means that we have this rather confusing control flow:
1. Original expression created and parsing attempted.
2. Expression with applied FixIts is created and parsing attempted.
3. Original expression is destroyed and parser deconstructed.
4. Expression with applied FixIts is destroyed and parser deconstructed.
This patch just deletes the original expression so that step 2 and 3 are
swapped and the whole process looks more like just sequentially parsing two
expressions (which is what we actually do here).
Doesn't fix anything just makes the code less fragile.
Summary:
TestInlineStepping tests LLDB's ability to step in the presence of
inline frames. The testcase source has a number of functions and some
of them are marked `always_inline`.
The test is built around the assumption that the inline function will
be fully represented once inlined, but this is not true with the
current arm64 code generation. For example:
void caller() {
always_inline_function(); // Step here
}
When stppeing into `caller()` above, you might immediatly end up in
the inlines frame for `always_inline_function()`, because there might
literally be no code associated with `caller()` itself.
This patch hacks around the issue by adding an `asm volatile("nop")`
on some lines with inlined calls where we expect to be able to
step. Like so:
void caller() {
asm volatile("nop"); always_inline_function(); // Step here
}
This guarantees there is always going to be one instruction for this
line in the caller.
Reviewers: labath, jingham
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76406
Summary:
TestBuiltinTrap fail on darwin embedded because the `__builin_trap`
builtin doesn't get any line info attached to it by clang when
building for arm64.
The test was already XFailed for linux arm(64), I presume for the same
reasons. This patch just XFails it independently of the platform.
Reviewers: labath
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76408
This reverts commit 939ca455e7.
This failed on the debian bot for some reason:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
"s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
This test was stripping a binary generated by Makefile.rules which is
potentially codesigned. Stripping invalidates the code signature, so
we might need to re-sign after stripping.
The test was stripping the binaries from the Python
code. Unfortunately, if running on darwin embedded in a context that
requires code signing, the stripping was invalidating the signature,
thus breaking the test.
This patch moves the stripping to the Makefile and resigns the
stripped binaries if required.
It was an inline test before. Clang stopped emitting line information
for the TLS initialization and the inline test didn't have a way to
break before it anymore.
This rewrites the test as a full-fldeged python test and improves the
checking of the error case to verify that the failure we are looking
for is related to the TLS setup not being complete.
The test checks that we correctly set the right number of breakpoints
when breaking into an `always_inline` function. The line of this
funstion selected for this test was the return statement, but with
recent compiler, this return statement doesn't necessarily exist after
inlining, even at O0.
Switch the breakpoint to a different line of the inline function.
Summary:
The memory history plugin for Asan creates a HistoryThread with the
recorded PC values provided by the Asan runtime. In other cases,
thoses PCs are gathered by LLDB directly.
The PCs returned by the Asan runtime are the PCs of the calls in the
backtrace, not the return addresses you would normally get when
unwinding the stack (look for a call to GetPreviousIntructionPc in
AsanGetStack).
When the above addresses are passed to the unwinder, it will subtract
1 from each address of the non zero frames because it treats them as
return addresses. This can lead to the final report referencing the
wrong line.
This patch fixes this issue by threading a flag through HistoryThread
and HistoryUnwinder that tells them to treat every frame like the
first one. The Asan MemoryHistory plugin can then use this flag.
This fixes running TestMemoryHistory on arm64 devices, although it's
hard to guarantee that the test will continue to exhibit the boundary
condition that triggers this bug.
Reviewers: jasonmolenda, kubamracek
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76341
D63643 added these testfiles but some of the %t4dwo and %t5dwo builds
are the same as corresponding %t4 and %t5 builds. Fortunately the
testcases do PASS.
After just adding -gsplit-dwarf these both skeleton files:
tools/lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test.tmp4dwo
tools/lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test.tmp5dwo
were referencing to this one non-skeleton file:
tools/lldb/test/SymbolFile/DWARF/debug-types-expressions.dwo
Surprisingly it does not affect the other test debug-types-basic.test
probably because it compiles to .o and then links it. While
debug-types-expressions.test compiles directly to an executable.
So fixed that while keeping the direct executable compilation.
Differential Revision: https://reviews.llvm.org/D76316
This patch changes the way the StackFrame Recognizers match a certain
frame.
Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).
Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.
rdar://60386577
Differential Revision: https://reviews.llvm.org/D76188
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Make sure that `process` is not None before calling is_alive. Otherwise
this might result in an AttributeError: 'NoneType' object has no
attribute 'is_alive'.
Although lldb.process and friends could already be None in the past, for
example after leaving an interactive scripting session, the issue became
more prevalent after `fc1fd6bf9fcfac412b10b4193805ec5de0e8df57`.
I audited the other interface files for usages of target, process,
thread and frame, but this seems the only place where a global is used
from an SB class.
The current implementation isn't very resilient when it comes to the
output of xcrun. Currently it cannot deal with:
- Trailing newlines.
- Leading newlines and errors/warnings before the Xcode path.
- Xcode not being named Xcode.app.
This extract the logic into a helper in PlatformDarwin and fixes those
issues. It's also the first step towards removing code duplication
between the different platforms and downstream Swift.
Differential revision: https://reviews.llvm.org/D76261
Fix to get the AST we generate for function templates closer to what clang generates and expects.
We fix which FuntionDecl we are passing to CreateFunctionTemplateSpecializationInfo and we strip
template parameters from the name when creating the FunctionDecl and FunctionTemplateDecl.
These two fixes together fix asserts and ambiguous lookup issues for several cases which are added to the already existing small function template test.
This fixes issues with overloads, overloads and ADL, variadic function templates and templated operator overloads.
Differential Revision: https://reviews.llvm.org/D75761
The error_stream and result parameter were inconsistently checked for
being null, so we might as well make them references instead of crashing
in case someone passes a nullptr and hits one of the code paths that are
currently not doing a nullptr check on those parameters. Also change
output_stream for consistency.
I believe the actual opcode does not matter because the AVR architecture
is a Harvard architecture that does not support writing to program
memory. Therefore, debuggers and emulators provide hardware breakpoints.
But for some reason, this opcode must be defined or else LLDB will crash
with an assertion error.
Differential Revision: https://reviews.llvm.org/D74255
This was previously crashing due to a missing nullptr check (see
e2d8aa6bf7 ). This just adds a test that should
make sure this doesn't crash in case a user ends up in this strange setup.
The GDB replay server sanity-checks that every packet it receives
matches what it expects from the serialized packet log. This mechanism
tripped for TestReproducerAttach.py on Linux, because one of the packets
(jModulesInfo) uses run-length encoding. The replay server was comparing
the expanded incoming packet with the unexpanded packet in the log. As a
result, it claimed to have received an unexpected packet, which caused
the test to fail.
This patch addresses that issue by expanding the run-length encoding
before comparing the packets.
Differential revision: https://reviews.llvm.org/D76163
The nullptr check here was removed in 4ef50a33b1
when I replaced (nearly) all log->Print to LLDB_LOG calls (which automatically
check for this stuff). But it seems this one call escaped my sed call.
Currently working on a test that can cover this code path but we can revert
this until I have found one.
Commit [1] added a declaration of function-member
StackFrame::BehavesLikeZerothFrame but hasn't added an implementation
for the function. This commit removes this declation, because the
function is not used anywhere.
[1] 31e6dbe1c6 Fix PC adjustment in StackFrame::GetSymbolContext
Differential Revision: https://reviews.llvm.org/D75979
Patch by Anton Kolesov <Anton.Kolesov@synopsys.com>
Fix to code from https://reviews.llvm.org/D64993.
Field StackFrame::m_behaves_like_zeroth_frame was introduced in commit
[1], however that commit hasn't added a copying of the field to
UpdatePreviousFrameFromCurrentFrame, therefore the value wouldn't change
when updating frames to reflect the current situation.
The particular scenario, where this matters is following. Assume we have
function main that invokes function func1. We set breakpoint at
func1 entry and in main after the func1 call, and do not stop at
the main entry. Therefore, when debugger stops for the first time,
func1 is frame#0, while main is frame#1, thus
m_behaves_like_zeroth_frame is set to 0 for main frame. Execution is
resumed, and stops now in main, where it is now frame#0. However while
updating the frame object, m_behaves_like_zeroth_frame remains false.
This field plays an important role when calculating line information for
backtrace: for frame#0, PC is the current line, therefore line
information is retrieved for PC, however for all other frames this is
not the case - calculated PC is a return-PC, i.e. instruction after the
function call line, therefore for those frames LLDB needs to step back
by one instruction. Initial implementation did this strictly for frames
that have index != 0 (and index is updated properly in
UpdatePreviousFrameFromCurrentFrame), but m_behaves_like_zeroth_frame
added a capability for middle-of-stack frames to behave in a similar
manner. But because current code now doesn't check frame idx,
m_behaves_like_zeroth_frame must be set to true for frames with 0 index,
not only for frame that behave like one. In the described test case,
after stopping in main, LLDB would still consider frame#0 as
non-zeroth, and would subtract instruction from the PC, and would report
previous like as current line.
The error doesn't manifest itself in LLDB interpreter though - it can be
reproduced through LLDB-MI and when using SB API, but not when we
interpreter command "continue" is executed. Honestly, I didn't fully
understand why it works in interpreter, I did found that bug "fixes"
itself if I enable DEBUG_STACK_FRAMES in StackFrameList.cpp, because
that calls StackFrame::Dump and that calls
GetSymbolContext(eSymbolContextEverything), which fills the context of
frame on the first breakpoint, therefore it doesn't have to be
recalculated (improperly) on a second frame. However, on first
breakpoint symbol context is calculated for the "call" line, not the
next one, therefore it should be recalculated anyway on a second
breakpoint, and it is done correctly, even though
m_behaves_like_zeroth_frame is still incorrect, as long as
GetSymbolContext(eSymbolContextEverything) has been called.
[1] 31e6dbe1c6 Fix PC adjustment in StackFrame::GetSymbolContext
Differential Revision: https://reviews.llvm.org/D75975
Patch by Anton Kolesov <Anton.Kolesov@synopsys.com>
Ideally we'd want all shebangs to be configurable, but that's not a
viable solution. Given that lldb-dotest is already configured, we might
as well make sure it uses the correct interpreter.
Differential revision: https://reviews.llvm.org/D76167
This patch extends the reproducers to intercept calls to FindProcesses.
During capture it serializes the ProcessInstanceInfoList returned by the
API. During replay, it returns the serialized data instead of querying
the host.
The motivation for this patch is supporting the process attach workflow
during replay. Without this change it would incorrectly look for the
inferior on the host during replay and failing if no matching process
was found.
Differential revision: https://reviews.llvm.org/D75877
Add YAML traits for ArchSpec and ProcessInstanceInfo so they can be
serialized for the reproducers.
Differential revision: https://reviews.llvm.org/D76004
In addition to the commit rG352f16db87f583ec7f55f8028647b5fd8616111f,
this one fixes settings behavior on clearing - the setting should be
reverted to their default value, not an empty one.
Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.
Differential revision: https://reviews.llvm.org/D76002
Since D75537 the test suite clears all settings before a test. This caused
two tests to fail:
lldb-api :: functionalities/inline-stepping/TestInlineStepping.py
lldb-api :: lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py
The reason for that is that OptionValueRegex::Clear was setting the regex
to empty instead of the default value that was passed initially. This caused
that the target.process.thread.step-avoid-regexp setting which is used in the
tests was set to "" instead of "^std::".
This patch is just a quick fix that sets the regex back to the original value
to make the tests pass.
In total these 3 setting values have changed with D75537 and also need to be
fixed (even though they don't seem to break any tests).
target.process.thread.step-avoid-regexp (regex) -> from '^std::' to empty string
platform.module-cache-directory (file) -> from "~/.lldb/module_cache" to empty string
script-lang (enum) -> from 'default' to 'python'
offset_t is unsigned, so if the RHS is signed we get a warning from clang:
warning: comparison of integers of different signs: 'const unsigned long long' and 'const int'
Global properties are shared between debugger instances and
if a test doesn't clear changes in settings it made,
this leads to side effects in other tests.
Differential Revision: https://reviews.llvm.org/D75537
If a producer emits a nonzero segment size, `lldb` will silently read
incorrect values and crash, or do something worse later as the tuple
size is expected to be 2, rather than 3.
Neither LLVM, nor GCC produce segmented aranges, but this dangerous case
should still be checked and handled.
Reviewed by: clayborg, labath
Differential Revision: https://reviews.llvm.org/D75925
Subscribers: lldb-commits
Tags: #lldb
Most clients of SourceManager.h need to do things like turning source
locations into file & line number pairs, but this doesn't require
bringing in FileManager.h and LLVM's FS headers.
The main code change here is to sink SM::createFileID into the cpp file.
I reason that this is not performance critical because it doesn't happen
on the diagnostic path, it happens along the paths of macro expansion
(could be hot) and new includes (less hot).
Saves some includes:
309 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h
272 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h
271 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h
267 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h
266 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h
Differential Revision: https://reviews.llvm.org/D75406
Module.h takes 86ms to parse, mostly parsing the class itself. Avoid it
if possible. ASTContext.h depends on ExternalASTSource.h.
A few NFC changes were needed to make this possible:
- Move ASTSourceDescriptor to Module.h. This needs Module to be
complete, and seems more related to modules and AST files than
external AST sources.
- Move "import complete" bit from Module* pointer int pair to
NextLocalImport pointer. Required because PointerIntPair<Module*,...>
requires Module to be complete, and now it may not be.
Reviewed By: aaron.ballman, hans
Differential Revision: https://reviews.llvm.org/D75784
Jonas Devlieghere