This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.
This relands commit aafa05e, reverted in 1f986f6.
Failed tests were fixed.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108233
Right now running `expr` to start the multiline expression editor and then
pressing enter causes an empty history empty to be created for the multiline
editor. That doesn't seem very useful for users as pressing the 'up' key will
now also bring up these empty expressions.
I don't think there is ever a use case for recalling a completely empty
expression from the history, so instead don't save those entries to the history
file and make sure we never recall them when navigating over the expression
history.
Note: This is actually a Swift downstream patch that got shipped with Apple's
LLDB for many years. However, this recently started conflicting with upstream
LLDB as D100048 added a test that made sure that empty expression entries don't
crash LLDB. Apple's LLDB was never affected by this crash as it never saved
empty expressions in the first place.
Reviewed By: augusto2112
Differential Revision: https://reviews.llvm.org/D108983
Remove software breakpoints from forked processes in order to restore
the original program code before detaching it.
Differential Revision: https://reviews.llvm.org/D100263
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D108233
When I run a lldb command that uses filename completion, if I enter a string
that is not only a filename but also a string with a non-file name string added,
such as "./" that is relative path string , it will crash as soon as I press the
[Tab] key. For example, debugging an executable file named "hello" that is
compiled from a file named "hello.c" , and I’ll put a breakpoint on line 3 of
hello.c.
```
$ lldb ./hello
(lldb) breakpoint set --file hello.c --line 3
```
This is not a problem, but if I set "--file ./hello." and then press [Tab] key
to complete file name, lldb crashes.
```
$ lldb ./hello
(lldb) breakpoint set --file ./hello.terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: __pos (which is 8) > this->size() (which is 7)
```
The crash was caused because substr() (in lldb/source/Host/common/Editline.cpp)
cut out string which size is user's input string from the completion string.
I modified the code that erase the user's intput string from current line and
then add the completion string.
Differential Revision: https://reviews.llvm.org/D108817
Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(and implicitly resumes the parent).
Differential Revision: https://reviews.llvm.org/D100206
It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.
The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D108510
added new command "process trace save -d <directory>".
-it saves a JSON file as <directory>/trace.json, with the main properties of the trace session.
-it saves binary Intel-pt trace as <directory>/thread_id.trace; each file saves each thread.
-it saves modules to the directory <directory>/modules .
-it only works for live process and it only support Intel-pt right now.
Example:
```
b main
run
process trace start
n
process trace save -d /tmp/mytrace
```
A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To load the trace that was just saved:
```
trace load /tmp/mytrace
thread trace dump instructions
```
You should see the instructions of the trace got printed.
To run a test:
```
cd ~/llvm-sand/build/Release/fbcode-x86_64/toolchain
ninja lldb-dotest
./bin/lldb-dotest -p TestTraceSave
```
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D107669
LLDB is using LLVM's target-specific disassembler which is only available when
the respective LLVM target has been enabled in the build config.
This patch just skips the test if there is no arm64 target (and its
disassembler) available in the current build config.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D108145
On aarch64 a two instruction sequence is used to calculate a
pc-relative address, add some state to the DisassemblerLLVMC
symbolicator so it can track the necessary data across the
two instructions and compute the address being calculated.
Differential Revision: https://reviews.llvm.org/D107213
rdar://49119253
Follow up on https://reviews.llvm.org/D105741
- Add new test that exhaustively checks the output file's content
- Fix typos in documentation and other minor fixes
Reviewed By: wallace
Original Author: jj10306
Differential Revision: https://reviews.llvm.org/D107674
These two tests, TestSkinnyCorefile.py and TestStackCorefile.py,
require a new debugserver on darwin systems to run correctly; for now,
skip them if the system debugserver is in use. There's no easy way to
test if the debugserver being used supports either of these memory
region info features. For end users, the fallback will be a full
corefile and that's not the worst thing, but for the tests it is a
problem.
The benefit of using assertIn is an improved error message when the
assertion fails:
AssertionError: False is not True
becomes
AssertionError: 'have ints 5 20 20 5' not found in '""'
Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack. Keep track of
memory regions that are stack memory in lldb. Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.
Differential Revision: https://reviews.llvm.org/D107625
LLDB evaluates some utility expression to update the Objective-C class list that
ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`.
This adds a test that just tries to define our own bogus version of
`objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we
currently don't have a way to tell LLDB to look for the function in a specific
library.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107778
We recently had an issue where a user declared a `Class::free` function which
then got picked up by accident by the expression evaluator when calling
`::free`. This was due to a too lax filter in the DWARFIndex (which was fixed by
https://reviews.llvm.org/D73191 ). This broke the Objective-C utility expression
that is trying to update the Objective-C class list (which is calling `:;free`).
This adds a regression test for situations where we have a bunch of functions
defined that share the name of the global functions that this utility function
calls. None of them are actually conflicting with the global functions we are
trying to call (they are all in namespaces, objects or classes).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107776
Use hexadecimal numbers rather than decimal in various vFile packets
in order to fix compatibility with gdbserver. This also changes the few
custom LLDB packets -- while technically they do not have to be changed,
it is easier to use the same syntax consistently across LLDB.
Differential Revision: https://reviews.llvm.org/D107475
Sync the mode constants used to drive vFile:open requests with these
used by GDB and defined for the gdb remote protocol. This makes it
possible to use 'platform file open' after connecting to gdbremote
server (and to some degree to operate on the open file modulo other
incompatibilities).
Differential Revision: https://reviews.llvm.org/D106985
Following tests fail on Arm/AArch64 randomly with timeouts:
TestMultilineNavigation.py
TestBatchMode.py
TestUnicode.py
TestGdbRemote_vContThreads.py
I am marking them as skipped until we find a away make to pass reliably.
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This reverts commit 34d78b6a67.
This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10: fatal error: 'objc/runtime.h' file not found
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This provides a convenient way to limit a breakpoint
to the current thread when setting it from the command line w/o
having to figure out what the current thread is.
Differential Revision: https://reviews.llvm.org/D107015
Following LLDB tests fail randomly on LLDB Arm/AArch64 Linux buildbots.
We still not have a reliable solution for these tests to pass
consistently. I am marking them skipped for now.
TestBreakpointCallbackCommandSource.py
TestIOHandlerResize.py
TestEditline.py
TestGuiViewLarge.py
TestGuiExpandThreadsTree.py
TestGuiBreakpoints.py
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with
matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if
eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the
same name (a typical examples would be constructors of templates with many
instantiations or overloaded operators).
Reviewers: labath, teemperor
Reviewed By: labath, teemperor
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
VScode now sends a "scopes" DAP request immediately after any expression evaluation.
This scopes request would clear and invalidate any non-scoped expandable variables in g_vsc.variables, causing later "variables" request to return empty result.
The symptom is that any expandable variables in VScode watch window/debug console UI to return empty content.
This diff fixes this issue by only clearing the expandable variables at process continue time. To achieve this, we have to repopulate all scoped variables
during context switch for each "scopes" request without clearing global expandable variables.
So the PR puts the scoped variables into its own locals/globals/registers; and all expandable variables into separate "expandableVariables" list.
Also, instead of using the variable index for "variableReference", it generates a new variableReference id each time as the key of "expandableVariables".
As a further new feature, this PR adds a new "expandablePermanentVariables" which has the lifetime of debug session. Any expandable variables from debug console
are added into this list. This enables users to snapshot expanable old variable in debug console and compare with new variables if desire.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D105166
The comment was originally added in 34769d80d. Then D44526
removed the flag added there (but kept the comment), and then
D66966 reintroduced a .noindex dir (which D68606 and then 33fca97880
moved around a bit).
No behavior change.
Differential Revision: https://reviews.llvm.org/D107341
This reverts commit fd18f0e84c.
I reverted this change to see its effect on failing GUI tests on LLDB
Arm/AArch64 Linux buildbots. I could not find any evidence against this
particular change so reverting it back.
Differential Revision: https://reviews.llvm.org/D100243
Following tests have been failing randomly on LLDB Arm and AArch64 Linux
builtbots:
TestMultilineNavigation.py
TestMultilineCompletion.py
TestIOHandlerCompletion.py
TestGuiBasic.py
I have increased allocated CPU resources to these bots but it has not
improved situation to an acceptable level. This patch marks them as
skipped on Arm/AArch64 for now.
The "memory tag read" command will now tell you
when the allocation tag read does not match the logical
tag.
(lldb) memory tag read mte_buf+(8*16) mte_buf+(8*16)+48
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7080, 0xfffff7ff7090): 0x8 (mismatch)
[0xfffff7ff7090, 0xfffff7ff70a0): 0x9
[0xfffff7ff70a0, 0xfffff7ff70b0): 0xa (mismatch)
The logical tag will be taken from the start address
so the end could have a different tag. You could for example
read from ptr_to_array_1 to ptr_to_array_2. Where the latter
is tagged differently to prevent buffer overflow.
The existing command will read 1 granule if you leave
off the end address. So you can also use it as a quick way
to check a single location.
(lldb) memory tag read mte_buf
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7000, 0xfffff7ff7010): 0x0 (mismatch)
This avoids the need for a seperate "memory tag check" command.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D106880
The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1
This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.
We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.
Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.
Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D104914
