(Addresses GH#62153)
The `SBType` APIs to retrieve details about template arguments,
such as `GetTemplateArgumentType` or `GetTemplateArgumentKind`
don't "desugar" LValueReferences/RValueReferences or pointers.
So when we try to format a `std::deque&`, the python call to
`GetTemplateArgumentType` fails to get a type, leading to
an `element_size` of `0` and a division-by-zero python exception
(which gets caught by the summary provider silently). This leads
to the contents of such `std::deque&` to be printed incorrectly.
This patch dereferences the reference/pointer before calling
into the above SBAPIs.
**Testing**
* Add API test
Differential Revision: https://reviews.llvm.org/D148531
- Separate the two test and only have TestSymbolFileJSON rely on strip.
- Use different file names to make sure LLDB reloads the module.
This should address all the post commit review from D148062.
Add MSP430 to the list of available targets, implement MSP430 ABI, add support for debugging targets with 16-bit address size.
The update is intended for use with MSPDebug, a GDB server implementation for MSP430.
Reviewed By: bulbazord, DavidSpickett
Differential Revision: https://reviews.llvm.org/D146965
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
With this patch, whenever we emit a `DW_AT_type` for some declaration
and the type is a template class with a `clang::PreferredNameAttr`, we
will emit the typedef that the attribute refers to instead. I.e.,
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x123 "basic_string<char>")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
```
...becomes
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x124 "std::string")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
0x125 DW_TAG_typedef
DW_AT_name "std::string"
DW_AT_type (0x124 "basic_string<char>")
```
We do this by returning the preferred name typedef `DIType` when
we create a structure definition. In some cases, e.g., with `-gmodules`,
we don't complete the structure definition immediately but do so later
via `completeClassData`, which overwrites the `TypeCache`. In such cases
we don't actually want to rewrite the cache with the preferred name. We
handle this by returning both the definition and the preferred typedef
from `CreateTypeDefinition` and let the callee decide what to do with
it.
Essentially we set up the types as:
```
TypeCache[Record] => DICompositeType
ReplaceMap[Record] => DIDerivedType(baseType: DICompositeType)
```
For now we keep this behind LLDB tuning.
**Testing**
- Added clang unit-test
- `check-llvm`, `check-clang` pass
- Confirmed that this change correctly repoints
`basic_string` references in some of my test programs.
- Will add follow-up LLDB API tests
Differential Revision: https://reviews.llvm.org/D145803
Currently, SBTarget::SetModuleLoadAddress does not accept large slides
needed to load images in high memory. This function should always have
taken an unsigned as the slide, as it immediately passes it to
Target::SetSectionLoadAddress which takes an unsigned.
This patch adds an overload and exposes that to SWIG instead of the
signed variant. I've marked the signed variant as deprecated and added
check that the slide is positive.
rdar://101355155
Differential revision: https://reviews.llvm.org/D147482
Step over thread plans were claiming to explain the fork stop reasons,
which prevented the default fork logic (detaching from the child
process) from kicking in. This patch changes that.
Differential Revision: https://reviews.llvm.org/D141605
Following the work done by @jdevlieghere in D143690, this changes how Clang module build
events are emitted.
Instead of one Progress event per module being built, a single Progress event is used to
encompass all modules, and each module build is sent as an `Increment` update.
Differential Revision: https://reviews.llvm.org/D147248
In a now-reverted series of patches, I inadvertently broke the ability
for lldb-server to explain a crash reason. To ensure that this feature
continues to work after future refactors, let's test the feature.
Differential Revision: https://reviews.llvm.org/D147001
In ee232506b8 I moved UnixSignal
initialization from lldbTarget to the various platform plugins. This
inadvertently broke lldb-server because lldb-server doesn't use
Platform plugins. lldb-server still needs to be able to create a
UnixSignals object for the host platform so we can add the relevant
platform plugin to lldb-server to make sure we always have a
HostPlatform.
Differential Revision: https://reviews.llvm.org/D146668
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
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
With this patch member-function pointers are formatted using
`CXXFunctionPointerSummaryProvider`.
This turns,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
into
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94 (a.out`Foo::member_func() at main.cpp:3)
```
Differential Revision: https://reviews.llvm.org/D145242
Before this patch, LLDB used to format pointers to members, such as,
```
void (Foo::*pointer_to_member_func)() = &Foo::member_func;
```
as `eFormatBytes`. E.g.,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) $1 = 94 3f 00 00 01 00 00 00 00 00 00 00 00 00 00 00
```
This patch makes sure we format pointers to member functions the same
way we do regular function pointers.
After this patch we format member pointers as:
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
Differential Revision: https://reviews.llvm.org/D145241
This patch adds a test for formatting of member function pointers.
This was split from https://reviews.llvm.org/D145242, which caused
this test case to fail on Windows buildbots.
I split this out in order to make sure that this indeed works on Windows
without the D145242 patch.
Differential Revision: https://reviews.llvm.org/D145487
This patch is a proof of concept that shows how a scripted process could
be used with real process to perform interactive debugging.
In this example, we run a process that spawns 10 threads. Then, we
create a intermediary scripted process who's job will be to wrap the
real process while intercepting it's process events and dispatching them
back either to the real process or to other child scripted processes.
In this example, we have 2 child scripted processes, with even and odd
thread indices. The goal is to be able to do thread filtering and
explore the various interactive debugging approaches, by letting a child
process running when stopping the other process and inspecting it.
Another approach would be to have the child processes execution in-sync
to force running every child process when one of them starts running.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When using SBProcess::GetScriptedImplementation in python, if the
process has a valid implementation, we returned a reference of the
object without incrementing the reference counting. That causes the
interpreter to crash after accessing the reference several times.
This patch address this by incrementing the reference count when passing
the valid object reference.
Differential Revision: https://reviews.llvm.org/D145260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds memory writing capabilities to the Scripted Process plugin.
This allows to user to get a target address and a memory buffer on the
python scripted process implementation that the user can make processing
on before performing the actual write.
This will also be used to write trap instruction to a real process
memory to set a breakpoint.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The goal of the simple patch is to clean-up the scripted process
interface by removing methods that were introduced with the interface
originally, but that were never really implemented (get_thread_with_id &
get_registers_for_thread).
This patch also changes `get_memory_region_containing_address` to have a
base implementation (that retunrs `None`), instead of forcing the user
to override it in their derived class.
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>
With this patch member-function pointers are formatted using
`CXXFunctionPointerSummaryProvider`.
This turns,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
into
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94 (a.out`Foo::member_func() at main.cpp:3)
```
Differential Revision: https://reviews.llvm.org/D145242
Before this patch, LLDB used to format pointers to members, such as,
```
void (Foo::*pointer_to_member_func)() = &Foo::member_func;
```
as `eFormatBytes`. E.g.,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) $1 = 94 3f 00 00 01 00 00 00 00 00 00 00 00 00 00 00
```
This patch makes sure we format pointers to member functions the same
way we do regular function pointers.
After this patch we format member pointers as:
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
Differential Revision: https://reviews.llvm.org/D145241
YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.
Differential Revision: https://reviews.llvm.org/D143727
This is a preparatory patch to add an SB API to get the progress data as
SBStructuredData. The advantage of using SBStructuredData is that the
dictionary can grow over time with more fields.
This approach is identical to the way this is implemented for diagnostic
events.
Differential revision: https://reviews.llvm.org/D143687
**Summary**
The compiler version check wouldn't make sense for non-GCC
compilers, so check for the compiler too.
Differential Revision: https://reviews.llvm.org/D143656
Depends on https://reviews.llvm.org/D142861.
Alternative to https://reviews.llvm.org/D137601.
xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.
Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.
Differential Revision: https://reviews.llvm.org/D142862
This patch should address a bug when a user have multiple scripted
processes in the same debugging session.
In order for the scripted process plugin to be able to call into the
scripted object instance methods to fetch the necessary data to
reconstruct its state, the scripted process plugin calls into a
scripted process interface, that has a reference to the created script
object instance.
However, prior to this patch, we only had a single instance of the
scripted process interface, living the script interpreter. So every time
a new scripted process plugin was created, it would overwrite the script
object instance that was held by the single scripted process interface
in the script interpreter.
That would cause all the method calls made to the scripted process
interface to be dispatched by the last instanciated script object
instance, which is wrong.
In order to prevent that, this patch moves the scripted process
interface reference to be help by the scripted process plugin itself.
rdar://104882562
Differential Revision: https://reviews.llvm.org/D143308
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new `GetScriptedImplementation` method to the
SBProcess class in the SBAPI. It will allow users of Scripted Processes to
fetch the scripted implementation object from to script interpreter to be
able to interact with it directly (without having to go through lldb).
This allows to user to perform action that are not specified in the
scripted process interface, like calling un-specified methods, but also
to enrich the implementation, by passing it complex objects.
Differential Revision: https://reviews.llvm.org/D143236
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
So far, the pretty printer for `std::coroutine_handle` internally
dereferenced the contained frame pointer displayed the `promise`
as a sub-value. As noticed in https://reviews.llvm.org/D132624
by @labath, this can lead to an endless loop in lldb during printing
if the coroutine frame pointers form a cycle.
This commit breaks the cycle by exposing the `promise` as a pointer
type instead of a value type. The depth to which the `frame variable`
and the `expression` commands dereference those pointers can be
controlled using the `--ptr-depth` argument.
Differential Revision: https://reviews.llvm.org/D132815
This patch skips TestStackCoreScriptedProcess because the test times out
when the Address Sanitizer is running.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Set compiler_versions on these tests, as they fail if tested on lower compiler
versions versions.
Differential Revision: https://reviews.llvm.org/D142513
