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.
Core components (not just the Core libraries but basically everything that's not a plugin) shouldn't depend on plugins. There's still places in LLDB where this is the case but @bulbazord has been hard at work to clean those up. This would introduce a new one. Can we avoid this?