Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications
to fix tests.
I originally reverted this because it caused a test to fail on Linux.
The problem was that I inverted a condition on accident.
There are many situations where we'll iterate over a SymbolContextList
with the pattern:
```
SymbolContextList sc_list;
// Fill in sc_list here
for (auto i = 0; i < sc_list.GetSize(); i++) {
SymbolContext sc;
sc_list.GetSymbolAtContext(i, sc);
// Do work with sc
}
```
Adding an iterator to iterate over the instances directly means we don't
have to do bounds checking or create a copy of every element of the
SymbolContextList.
Differential Revision: https://reviews.llvm.org/D149900
FileSpec::GetFileNameExtension returns a StringRef. In some cases we
are calling it and then storing the result in a local. To prevent
cases where we store the StringRef, mutate the Filespec, and then try to
use the stored StringRef afterwards, I've audited the callsites and made
adjustments to mitigate: Either marking the FileSpec it comes from as
const (to avoid mutations) or by not storing the StringRef in a local if
it makes sense not to.
Differential Revision: https://reviews.llvm.org/D149671
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.
These don't really need to be in ConstStrings. It's nice that comparing
ConstStrings is fast (just a pointer comparison) but the cost of
creating the ConstString usually already includes the cost of doing a
StringRef comparison anyway, so this is just extra work and extra memory
consumption for basically no benefit.
Differential Revision: https://reviews.llvm.org/D149300
This is useful in contexts where you have multiple languages in play:
You may be stopped in a frame for language A, but want to set a watchpoint
with an expression using language B. The current way to do this is to
use the setting `target.language` while setting the watchpoint and
unset it after the watchpoint is set, but that's kind of clunky and
somewhat error-prone. This should add a better way to do this.
rdar://108202559
Differential Revision: https://reviews.llvm.org/D149111
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.
This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.
However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.
So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.
Differential Revision: https://reviews.llvm.org/D148863
Previously if a register had fields we would always print them after the
value if the register was asked for by name.
```
(lldb) register read MDCR_EL3
MDCR_EL3 = 0x00000000
= {
ETBAD = 0
<...>
RLTE = 0
}
```
This can be quite annoying if there are a whole lot of fields but you
want to see the register in a specific format.
```
(lldb) register read MDCR_EL3 -f i
MDCR_EL3 = 0x00000000 unknown udf #0x0
= {
ETBAD = 0
<...lots of fields...>
```
Since it pushes the interesting bit far up the terminal. To solve this,
don't print fields if the user passes --format. If they're doing that
then I think it's reasonable to assume they know what they want and only
want to see that output.
This also gives users a way to silence fields, but not change the format.
By doing `register read foo -f x`. In case they are not useful or perhaps
they are trying to work around a crash.
I have customised the help text for --format for register read to explain this:
```
-f <format> ( --format <format> )
Specify a format to be used for display. If this is set, register fields will not be dispayed.
```
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D148790
This change uses the information from target.xml sent by
the GDB stub to produce C types that we can use to print
register fields.
lldb-server *does not* produce this information yet. This will
only work with GDB stubs that do. gdbserver or qemu
are 2 I know of. Testing is added that uses a mocked lldb-server.
```
(lldb) register read cpsr x0 fpcr fpsr x1
cpsr = 0x60001000
= (N = 0, Z = 1, C = 1, V = 0, TCO = 0, DIT = 0, UAO = 0, PAN = 0, SS = 0, IL = 0, SSBS = 1, BTYPE = 0, D = 0, A = 0, I = 0, F = 0, nRW = 0, EL = 0, SP = 0)
```
Only "register read" will display fields, and only when
we are not printing a register block.
For example, cpsr is a 32 bit register. Using the target's scratch type
system we construct a type:
```
struct __attribute__((__packed__)) cpsr {
uint32_t N : 1;
uint32_t Z : 1;
...
uint32_t EL : 2;
uint32_t SP : 1;
};
```
If this register had unallocated bits in it, those would
have been filled in by RegisterFlags as anonymous fields.
A new option "SetChildPrintingDecider" is added so we
can disable printing those.
Important things about this type:
* It is packed so that sizeof(struct cpsr) == sizeof(the real register).
(this will hold for all flags types we create)
* Each field has the same storage type, which is the same as the type
of the raw register value. This prevents fields being spilt over
into more storage units, as is allowed by most ABIs.
* Each bitfield size matches that of its register field.
* The most significant field is first.
The last point is required because the most significant bit (MSB)
being on the left/top of a print out matches what you'd expect to
see in an architecture manual. In addition, having lldb print a
different field order on big/little endian hosts is not acceptable.
As a consequence, if the target is little endian we have to
reverse the order of the fields in the value. The value of each field
remains the same. For example 0b01 doesn't become 0b10, it just shifts
up or down.
This is needed because clang's type system assumes that for a struct
like the one above, the least significant bit (LSB) will be first
for a little endian target. We need the MSB to be first.
Finally, if lldb's host is a different endian to the target we have
to byte swap the host endian value to match the endian of the target's
typesystem.
| Host Endian | Target Endian | Field Order Swap | Byte Order Swap |
|-------------|---------------|------------------|-----------------|
| Little | Little | Yes | No |
| Big | Little | Yes | Yes |
| Little | Big | No | Yes |
| Big | Big | No | No |
Testing was done as follows:
* Little -> Little
* LE AArch64 native debug.
* Big -> Little
* s390x lldb running under QEMU, connected to LE AArch64 target.
* Little -> Big
* LE AArch64 lldb connected to QEMU's GDB stub, which is running
an s390x program.
* Big -> Big
* s390x lldb running under QEMU, connected to another QEMU's GDB
stub, which is running an s390x program.
As we are not allowed to link core code to plugins directly,
I have added a new plugin RegisterTypeBuilder. There is one implementation
of this, RegisterTypeBuilderClang, which uses TypeSystemClang to build
the CompilerType from the register fields.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D145580
Since each `DumpModuleInfoAction` can now contain a pointer to a
`raw_ostream`, saving there a poiter that owned by a local `unique_ptr`
may cause use-after-free. Clarify ownership and save a `shared_ptr`
inside of `DumpModuleInfoAction` instead.
Found by static analyzer.
Reviewed By: tahonermann, aaron.ballman
Differential Revision: https://reviews.llvm.org/D146412
When printing a value, allow the root value's name to be elided, without omiting the
names of child values.
At the API level, this adds `SetHideRootName()`, which joins the existing
`SetHideName()` function.
This functionality is used by `dwim-print` and `expression`.
Fixes an issue identified by @jgorbe in https://reviews.llvm.org/D145609.
Differential Revision: https://reviews.llvm.org/D146783
Non-plugin lldb libraries should generally not be linking against lldb
plugin libraries. Enforce this in CMake.
Differential Revision: https://reviews.llvm.org/D146553
Change `dwim-print` to now disable persistent results by default, unless requested by
the user with the `--persistent-result` flag.
Ex:
```
(lldb) dwim-print 1 + 1
(int) 2
(lldb) dwim-print --persistent-result on -- 1 + 1
(int) $0 = 2
```
Users who wish to enable persistent results can make and use an alias that includes
`--persistent-result on`.
Updates: To recommit this, both TestPersistentResult.py and TestPAlias.py needed to be
updated, as well as the changes in D146230.
Differential Revision: https://reviews.llvm.org/D145609
LLDB uses `_up`, `_sp` and `_wp` suffixes for unique, shared and weak
pointers respectively. This can become confusing in combination with
watchpoints which are commonly abbreviated to `wp`. Update
CommandObjectWatchpoint to use `watch_sp` for all `WatchpointSP`
variables.
When setting a variable watchpoint, the watchpoint stores the variable
name in the watchpoint spec. For expression variables we should store
the expression in the watchpoint spec. This patch adds that
functionality.
rdar://106096860
Differential revision: https://reviews.llvm.org/D146262
Change `dwim-print` to now disable persistent results by default, unless requested by
the user with the `--persistent-result` flag.
Ex:
```
(lldb) dwim-print 1 + 1
(int) 2
(lldb) dwim-print --persistent-result on -- 1 + 1
(int) $0 = 2
```
Users who wish to enable persistent results can make and use an alias that includes
`--persistent-result on`.
Differential Revision: https://reviews.llvm.org/D145609
Fix logic for repeat commands, so that regex commands (specificially `bt`) are
given the opportunity to provide a repeat command.
rdar://104562616
Differential Revision: https://reviews.llvm.org/D143695
This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.
It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
process state is already script, however, this allows to create a
scripted process without requiring to have an executuble in the target.
In order to do so, this patch also turns the scripted process related
getters and setters from the `ProcessLaunchInfo` and
`ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves
it in the `ProcessInfo` class, so it can be accessed interchangeably.
This also adds the necessary SWIG wrappers to convert the internal
`Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it
as argument the scripted process python implementation and convert it
back to the internal representation.
rdar://104577406
Differential Revision: https://reviews.llvm.org/D143104
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch does several things:
First, it refactors the `CommandObject{,Platform}ProcessObject` command
option class into a separate `CommandOptionsProcessAttach` option group.
This will make sure both the `platform process attach` and `process attach`
command options will always stay in sync without having with duplicate
them each time. But more importantly, making this class an `OptionGroup`
allows us to combine with a `OptionGroupPythonClassWithDict` to add
support for the scripted process managing class name and user-provided
dictionary options.
This patch also improves feature parity between `ProcessLaunchInfo` and
`ProcessAttachInfo` with regard to ScriptedProcesses, by exposing the
various getters and setters necessary to use them through the SBAPI.
This is foundation work for adding support to "attach" to a process from
the scripted platform.
Differential Revision: https://reviews.llvm.org/D139945
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In order to run a {break,watch}point command, lldb can resolve to the
script interpreter to run an arbitrary piece of code or call into a
user-provided function. To do so, we will generate a wrapping function,
where we first copy lldb's internal dictionary keys into the
interpreter's global dictionary, copied inline the user code before
resetting the global dictionary to its previous state.
However, {break,watch}point commands can optionally return a value that
would tell lldb whether we should stop or not. This feature was
only implemented for breakpoint commands and since we inlined the user
code directly into the wrapping function, introducing an early return,
that caused lldb to let the interpreter global dictionary tinted with the
internal dictionary keys.
This patch fixes that issue while also adding the stopping behaviour to
watchpoint commands.
To do so, this patch refactors the {break,watch}point command creation
method, to let the lldb wrapper function generator know if the user code is
a function call or a arbitrary expression.
Then the wrapper generator, if the user input was a function call, the
wrapper function will call the user function and save the return value into
a variable. If the user input was an arbitrary expression, the wrapper will
inline it into a nested function, call the nested function and save the
return value into the same variable. After resetting the interpreter global
dictionary to its previous state, the generated wrapper function will return
the varible containing the return value.
rdar://105461140
Differential Revision: https://reviews.llvm.org/D144688
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Context: The `expression` command uses artificial variables to store the expression
result. This result variable is unconditionally kept around after the expression command
has completed. These variables are known as persistent results. These are the variables
`$0`, `$1`, etc, that are displayed when running `p` or `expression`.
This change allows users to control whether result variables are persisted, by
introducing a `--persistent-result` flag.
This change keeps the current default behavior, persistent results are created by
default. This change gives users the ability to opt-out by re-aliasing `p`. For example:
```
command unalias p
command alias p expression --persistent-result false --
```
For consistency, this flag is also adopted by `dwim-print`. Of note, if asked,
`dwim-print` will create a persistent result even for frame variables.
Differential Revision: https://reviews.llvm.org/D144230
Adopt `expression`'s options in `dwim-print`.
This is primarily added to support the `--language`/`-l` flag.
Differential Revision: https://reviews.llvm.org/D144114
Remove the persistent result variable after executing `po`.
Without this change, the following behavior happens:
```
(lldb) p thing
(NSObject *) $0 = 0x600000008000
(lldb) po thing
<NSObject: 0x600000008000>
(lldb) p thing
(NSObject *) $2 = 0x600000008000
(lldb) p $1
(NSObject *) $1 = 0x600000008000
```
Even though `po` hides the persistent result variable, it's still created - as $1 in
this example. It can be accessed even though its existence is not evident.
With this change, the persistent result is removed after the object description has
printed. Instead, this is the behavior:
```
(lldb) p thing
(NSObject *) $0 = 0x600000008000
(lldb) po thing
<NSObject: 0x600000008000>
(lldb) p thing
(NSObject *) $1 = 0x600000008000
```
The difference here is that the `po` doens't silently create a persistent result.
Differential Revision: https://reviews.llvm.org/D144044
lldb was originally designed to get the watchpoint exception behavior
from the gdb remote serial protocol stub -- exceptions are either
received before the instruction executes, or after the instruction
has executed. This behavior was reported via two lldb extensions
to gdb RSP, so generic remote stubs like gdbserver or a JTAG stub,
would not tell lldb which behavior was correct, and it would default
to "exceptions are received after the instruction has executed".
Two architectures hard coded their correct "exceptions before
instruction" behavior, to work around this issue.
Most architectures have a fixed behavior of watchpoint exceptions,
and we can center that information in lldb. We can allow a remote
stub to override the default behavior via our packet extensions
if it's needed on a specific target.
This patch also separates the fetching of the number of watchpoints
from whether exceptions are before/after the insn. Currently if
lldb couldn't fetch the number of watchpoints (not really needed), it
also wouldn't get when exceptions are received, and watchpoint
handling would fail. lldb doesn't actually use the number of
watchpoints for anything beyond printing it to the user.
Differential Revision: https://reviews.llvm.org/D143215
rdar://101426626
This is a follow up to https://reviews.llvm.org/D141629
and applies the change it made to all paths through ToAddress
(now DoToAddress).
I have included the test from my previous attempt
https://reviews.llvm.org/D136938.
The initial change only applied fixing to addresses that
would parse as integers, so my test case failed. Since
ToAddress has multiple exit points, I've wrapped it into
a new method DoToAddress.
Now you can call ToAddress, it will call DoToAddress and
no matter what path you take, the address will be fixed.
For the memory tagging commands we actually want the full
address (to work out mismatches). So I added ToRawAddress
for that.
I have tested this on a QEMU AArch64 Linux system with
Memory Tagging, Pointer Authentication and Top Byte Ignore
enabled. By running the new test and all other tests in
API/linux/aarch64.
Some commands have had calls to the ABI plugin removed
as ToAddress now does this for them.
The "memory region" command still needs to use the ABI plugin
to detect the end of memory when there are non-address bits.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D142715
Print an error for unsupported combinations of log handlers and log
options. Only the stream log handler takes a file and only the circular
and stream handler take a buffer size. This cannot be dealt with through
option groups because the option combinations depend on the requested
handler.
Differential revision: https://reviews.llvm.org/D143623
When using --name, due to a missing newline, multiple symbol results
were not correctly printed:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in <...>/tbi_lisp:
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:75 Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:82
```
It should be:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in /home/david.spickett/tbi_lisp/tbi_lisp:
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:75
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:82
```
With Address/Summary on separate lines.
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D143564
Add support for the `--gdb-format`/`-G` flag to `dwim-print`.
The gdb-format flag allows users to alias `p` to `dwim-print`.
Differential Revision: https://reviews.llvm.org/D141425
This is processed by hand in CommandObjectMultiword, and is undiscoverable,
it doesn't work in all cases. Because it is a bare word, it can't really be
extended w/o introducing the possibility of collisions as well. If we did
want to do something like this we should add a --help flag to CommandObject. That
way the feature would be consistent and documented.
Differential Revision: https://reviews.llvm.org/D142067
Before:
```
(lldb) expr --language abc -- 1 + 1
error: unknown language type: 'abc' for expression
```
After:
```
(lldb) expr --language abc -- 1 + 1
error: unknown language type: 'abc' for expression. List of supported languages:
c++
objective-c++
c++03
c++11
c++14
objc++
```
We choose to only list the languages which `expr` will actually
accept instead of all the language constants defined in `Language.cpp`
since that's what the user will most likely need.
Differential Revision: https://reviews.llvm.org/D142034
This claims to take a platform name argument but doesn't.
That was probably the intent in fbb7634934d40548b650574a2f2a85ab41527674
but it has only ever worked with the current platform.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D136928
