Update examples and docs to demonstrate using `__lldb_init_module` instead of
the idiom that checks for `lldb.debugger` at the top-level.
```
if __name__ == '__main__':
...
elif lldb.debugger:
...
```
Is replaced with:
```
if __name__ == '__main__':
...
def __lldb_init_module(debugger, internal_dict):
...
```
This change is for two reasons. First, it's generally encouraged not to only
use the convenience singletons (`lldb.{debugger,process,target,etc}`)
interactively from the `script` command. Second, there's a bug where
registering a python class as a command (using `command script add -c ...`),
result in the command not being runnable. Note that registering function-backed
commands does not have this bug.
Differential Revision: https://reviews.llvm.org/D117237
When LLDB receives a SIGINT while running the embedded Python REPL it
currently just crashes in ScriptInterpreterPythonImpl::Interrupt with an
error such as the one below:
Fatal Python error: PyThreadState_Get: the function must be called
with the GIL held, but the GIL is released (the current Python thread
state is NULL)
The faulty code that causes this error is this part of
ScriptInterpreterPythonImpl::Interrupt:
PyThreadState *state = PyThreadState_GET();
if (!state)
state = GetThreadState();
if (state) {
long tid = state->thread_id;
PyThreadState_Swap(state);
int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);
The obvious fix I tried is to just acquire the GIL before this code is
running which fixes the crash but the KeyboardInterrupt we want to raise
immediately is actually just queued and would only be raised once the
next line of input has been parsed (which e.g. won't interrupt Python
code that is currently waiting on a timer or IO from what I can see).
Also none of the functions we call here is marked as safe to be called
from a signal handler from what I can see, so we might still end up
crashing here with some bad timing.
Python 3.2 introduced PyErr_SetInterrupt to solve this and the function
takes care of all the details and avoids doing anything that isn't safe
to do inside a signal handler. The only thing we need to do is to
manually setup our own fake SIGINT handler that behaves the same way as
the standalone Python REPL signal handler (which raises a
KeyboardInterrupt).
From what I understand the old code used to work with Python 2 so I kept
the old code around until we officially drop support for Python 2.
There is a small gap here with Python 3.0->3.1 where we might still be
crashing, but those versions have reached their EOL more than a decade
ago so I think we don't need to bother about them.
Differential revision: https://reviews.llvm.org/D104886
Convert the `crashlog` command to be implemented as a class. The `Symbolicate`
function is switched to a class, to implement `get_long_help`. The text for the
long help comes from the help output generated by `OptionParser`. That is, the
output of `help crashlog` is the same as `crashlog --help`.
Differential Revision: https://reviews.llvm.org/D117165
This was left over from when I had used some pointer authentication
instructions to sign the pointer. Then I realised that simply setting
the top byte is enough to prove the ABI plugin is being called.
Top byte ignore is a feature of the armv8-a architecure and doesn't
need any extra compiler flags.
Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread. This is currently
implemented on FreeBSD and Linux.
Differential Revision: https://reviews.llvm.org/D117113
Set the current thread ID to the thread where an event happened.
As a result, e.g. when a signal is delivered to a thread other than
the first one, the respective T packet refers to the signaled thread
rather than the first thread (with no stop reason). While this doesn't
strictly make a difference to the LLDB client, it is the expected
behavior.
Differential Revision: https://reviews.llvm.org/D117103
Due to a missing cast the << 60 always resulted in zero leaving
the top nibble empty. So we weren't actually testing that lldb
ignores those bits in addition to the tag bits.
Correct that and also set the top nibbles to ascending values
so that we can catch if lldb only removes one of the tag bits
and top nibble, but not both.
In future the tag manager will likely only remove the tag bits
and leave non-address bits to the ABI plugin but for now make
sure we're testing what we claim to implement.
"shell" is an alias to "platform shell -h --". Previously you would get this
help text:
(lldb) help shell
Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.)
Syntax: shell <shell-command>
Command Options Usage:
'shell' is an abbreviation for 'platform shell -h --'
Since the code doesn't handle the base command having options
but the alias removing them. With these changes you get:
(lldb) help shell
Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.)
Syntax: shell <shell-command>
'shell' is an abbreviation for 'platform shell -h --'
Note that we already handle a non-alias command having no options,
for example "quit":
(lldb) help quit
Quit the LLDB debugger.
Syntax: quit [exit-code]
Reviewed By: JDevlieghere, jingham
Differential Revision: https://reviews.llvm.org/D117004
This adds inline function support to NativePDB by parsing S_INLINESITE records
to retrieve inlinee line info and add them into line table at `ParseLineTable`.
Differential Revision: https://reviews.llvm.org/D116845
Several of the comments were annotating the wrong argument.
I caught this while reviewing this clean-up: 8afcfbfb8f
which was changing booleans to use true and false and in the this case the comment and the type looked mismatched.
Differential Revision: https://reviews.llvm.org/D116982
Addresses on AArch64 can have top byte tags, memory tags and pointer
authentication signatures in the upper bits.
While testing memory tagging I found that memory read couldn't
read a range if the two addresses had different tags. The same
could apply to signed pointers given the right circumstance.
(lldb) memory read mte_buf_alt_tag mte_buf+16
error: end address (0x900fffff7ff8010) must be greater than the start
address (0xa00fffff7ff8000).
Or it would try to read a lot more memory than expected.
(lldb) memory read mte_buf mte_buf_alt_tag+16
error: Normally, 'memory read' will not read over 1024 bytes of data.
error: Please use --force to override this restriction just once.
error: or set target.max-memory-read-size if you will often need a
larger limit.
Fix this by removing non address bits before we calculate the read
range. A test is added for AArch64 Linux that confirms this by using
the top byte ignore feature.
This means that if you do read with a tagged pointer the output
does not include those tags. This is potentially confusing but I think
overall it's better that we don't pretend that we're reading memory
from a range that the process is unable to map.
(lldb) p ptr1
(char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff"
(lldb) p ptr2
(char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff"
(lldb) memory read ptr1 ptr2+16
0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00 ........8p......
Reviewed By: omjavaid, danielkiss
Differential Revision: https://reviews.llvm.org/D103626
Previously we would persist the flags indicating whether the remote side
supports a particular feature across reconnects, which is obviously not
a good idea.
I implement the clearing by nuking (its the only way to be sure :) the
entire GDBRemoteCommunication object in the disconnect operation and
creating a new one upon connection. This allows us to maintain a nice
invariant that the GDBRemoteCommunication object (which is now a
pointer) exists only if it is connected. The downside to that is that a
lot of functions now needs to check the validity of the pointer instead
of blindly accessing the object.
The process communication does not suffer from the same issue because we
always destroy the entire Process object for a relaunch.
Differential Revision: https://reviews.llvm.org/D116539
If LLVM is configured without X86 as one of its TARGETS_TO_BUILD, then lldb
will crash when using X86 disassembler (which it does while running `image
show-unwind`).
While working on D116788 (properly error out of `frame var`), this libstdc++
specific `frame var` invocation was found in the tests. This test is in the
generic directory, but has this one case that requires libstdc++. The fix here
is to put the one `expect()` inside of a condition that checks for libstdc++.
Differential Revision: https://reviews.llvm.org/D116901
This test checks for `aarch64` but the lit config could also contain `arm64`.
This change adds `arm64` to make the test pass in all cases.
Differential Revision: https://reviews.llvm.org/D116912
Ensure that errors in `frame variable` are reflected in result object.
The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.
This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.
Differential Revision: https://reviews.llvm.org/D116788
(cherry picked from commit 2c7d10c412)
Fixes incomplete command names in `apropos` results.
The full command names given by `apropos` have come from command name string
literals given to `CommandObject` constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
`apropos` output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.
There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the `language objc` subcommand
has to set its command name string to "objc", which results in apropos printing
results as `objc ...` instead of `language objc ...`.
To fix both of these issues, this commit changes `FindCommandsForApropos` to
derive the fully qualified command name using the keys of subcommand maps.
Differential Revision: https://reviews.llvm.org/D116491
(cherry picked from commit b3bfd595a5)
Simplify getting the length of `NSPathStore2` strings.
`NSStringSummaryProvider` uses a single field from `NSPathStore2` instances,
its first ivar: `_lengthAndRefCount`. This change uses
`GetSyntheticChildAtOffset` to replace the use of `ProcessStructReader`, and
removes the hard coded `CompilerType` definition of `NSPathStore2`.
Differential Revision: https://reviews.llvm.org/D116461
Ensure that errors in `frame variable` are reflected in result object.
The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.
This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.
Differential Revision: https://reviews.llvm.org/D116788
The lldbconfig module was necessary to run the LLDB test suite against a
reproducer. Since this functionality has been removed, the module is no
longer necessary.
Both close and closesocket should return 0 on success so using !! looks incorrect. I replaced this will a more readable == 0 check.
Differential Revision: https://reviews.llvm.org/D116768
When printing a std::string_view, print the referenced string as the
summary. Support string_view, u32string_view, u16string_view and
wstring_view, as we do for std::string and friends.
This is based on the existing fomratter for std::string, and just
extracts the data and length members, pushing them through the existing
string formatter.
In testing this, a "FIXME" was corrected for printing of non-ASCII empty
values. Previously, the "u", 'U" etc. prefixes were not printed for
basic_string<> types that were not char. This is trivial to resolve by
printing the prefix before the "".
Differential revision: https://reviews.llvm.org/D112222
Fixes incomplete command names in `apropos` results.
The full command names given by `apropos` have come from command name string
literals given to `CommandObject` constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
`apropos` output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.
There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the `language objc` subcommand
has to set its command name string to "objc", which results in apropos printing
results as `objc ...` instead of `language objc ...`.
To fix both of these issues, this commit changes `FindCommandsForApropos` to
derive the fully qualified command name using the keys of subcommand maps.
Differential Revision: https://reviews.llvm.org/D116491
Include the complete list of threads of all running processes
in the FreeBSDKernel plugin. This makes it possible to inspect
the states (including partial register dumps from PCB) of all kernel
and userspace threads at the time of crash, or at the time of reading
/dev/mem first.
Differential Revision: https://reviews.llvm.org/D116255
Dave Lee