lldb does not support "<vector>" and "<union>" when describing registers

[DavidSpickett]

This was reported to me by someone trying to debug SVE and SME code that switched streaming modes, using qemu-user. When in streaming mode they could not read the Z registers but they could in non-streaming mode. Qemu was returning valid data each time but lldb refused to display it in streaming mode.

The cause is a difference in how lldb-server and qemu describe the type of these registers. lldb-server describes them as:

<reg name="z31" bitsize="256" regnum="193" encoding="vector" format="vector-uint8" group="Scalable Vector Extension Registers" ehframe_regnum="127" dwarf_regnum="127" />

And this gets converted to eEncodingVector. We can see that lldb-server sets that in the source:

// Defines a Z vector register with 16-byte default size
#define DEFINE_ZREG(reg)                                                       \
  {                                                                            \
    #reg, nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,   \
        SVE_REG_KIND(reg), nullptr, nullptr, nullptr,                          \
  }

This format lets us handle any amount of elements in the vector. So if you increase the vector length, no problem.

qemu on the other hand uses <vector> and <union> (see https://sourceware.org/gdb/current/onlinedocs/gdb.html/Target-Description-Format.html):

<vector id="svevqu" type="uint128" count="16"/>
<...>
</union><union id="svev">
  <field name="q" type="svevnq"/>
  <field name="d" type="svevnd"/>
  <field name="s" type="svevns"/>
  <field name="h" type="svevnh"/>
  <field name="b" type="svevnb"/>
</union>
<reg name="z0" bitsize="2048" regnum="34" type="svev"/>

lldb doesn't recognise the type svev and so defaults to unsigned int. That goes through

llvm-project/lldb/source/Utility/RegisterValue.cpp

Line 189 in e05c1b4

case eEncodingUint:

which only supports up to 128 bit numbers. So you can read the Z registers if the vector length is less than 128 bits (vg = 2) but as soon as it goes beyond that, lldb rejects the data.

The example I was given used streaming mode and set qemu's SVE/SME default vector lengths like:

-cpu max,sve-default-vector-length=16,sme-default-vector-length=64

But you can also reproduce by writing vg from within lldb register write vg 4.

We could add some arbitrary sized integer support (Scalar already stores the value using APSInt and APFloat). This would be the quick fix.

Long term we should support <vector> and <union> as they do have some advantages. <union> causes the debugger to display the vector in multiple ways, which can be useful for SVE where you don't know what type is in the register at a given point.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: David Spickett (DavidSpickett)

Details

This was reported to me by someone trying to debug SVE and SME code that switched streaming modes, using qemu-user. When in streaming mode they could not read the Z registers but they could in non-streaming mode. Qemu was returning valid data each time but lldb refused to display it in streaming mode.

The cause is a difference in how lldb-server and qemu describe the type of these registers. lldb-server describes them as:

<reg name="z31" bitsize="256" regnum="193" encoding="vector" format="vector-uint8" group="Scalable Vector Extension Registers" ehframe_regnum="127" dwarf_regnum="127" />

And this gets converted to eEncodingVector. We can see that lldb-server sets that in the source:

// Defines a Z vector register with 16-byte default size
#define DEFINE_ZREG(reg)                                                       \
  {                                                                            \
    #reg, nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,   \
        SVE_REG_KIND(reg), nullptr, nullptr, nullptr,                          \
  }

This format lets us handle any amount of elements in the vector. So if you increase the vector length, no problem.

qemu on the other hand uses <vector> and <union> (see https://sourceware.org/gdb/current/onlinedocs/gdb.html/Target-Description-Format.html):

<vector id="svevqu" type="uint128" count="16"/>
<...>
</union><union id="svev">
  <field name="q" type="svevnq"/>
  <field name="d" type="svevnd"/>
  <field name="s" type="svevns"/>
  <field name="h" type="svevnh"/>
  <field name="b" type="svevnb"/>
</union>
<reg name="z0" bitsize="2048" regnum="34" type="svev"/>

lldb doesn't recognise the type svev and so defaults to unsigned int. That goes through

llvm-project/lldb/source/Utility/RegisterValue.cpp

Line 189 in e05c1b4

case eEncodingUint:

which only supports up to 128 bit numbers. So you can read the Z registers if the vector length is less than 128 bits (vg = 2) but as soon as it goes beyond that, lldb rejects the data.

The example I was given used streaming mode and set qemu's SVE/SME default vector lengths like:

-cpu max,sve-default-vector-length=16,sme-default-vector-length=64

But you can also reproduce by writing vg from within lldb register write vg 4.

We could add some arbitrary sized integer support (Scalar already stores the value using APSInt and APFloat). This would be the quick fix.

Long term we should support <vector> and <union> as they do have some advantages. <union> causes the debugger to display the vector in multiple ways, which can be useful for SVE where you don't know what type is in the register at a given point.

[DavidSpickett]

For <union> we can model this as a C union type and it would work for unions of <flags> types. For vectors if they are sized we could make C types as arrays but if they are scalable then that's more tricky. One option is to convert them into lldb's preferred formatting options.

Also now I see that these union types are sized, so I wonder what happens when the vector length changes. It's possible qemu changes the representation, which we won't pick up because we I don't think we re-parse all the XML.

[DavidSpickett]

Currently the C struct types we make have a big endian layout, and we compensate for that by swapping the over of the fields in the value if the target's endian is not big.

This presents a problem for union of flags. If two union members are flags with different layouts, we can't supply one value that's the correct order for both.

This might extend to union of vector as well, but I'm not about to melt my mind trying to reason about that yet.

So although the GDB spec does not prohibit nesting these types arbitrarily, we may have to add some restrictions just to make it implementable.

[DavidSpickett]

One option here might be to define the structs in an order that matches the endian of the value that we have, then print the struct members in reverse order. Then the one value contained in the union can be correct for all of the flags members.

[DavidSpickett]

So far I got Neon working:

(lldb) register read v0
      v0 = {0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f}
         = {
             d = {
               f = (7.9499288951273625E-275, 3.6919162048650923E-236)
               u = (506097522914230528, 1084818905618843912)
               s = (506097522914230528, 1084818905618843912)
             }
             s = {
               f = (3.82047143E-37, 1.00825135E-34, 2.65846276E-32, 7.00365327E-30)
               u = (50462976, 117835012, 185207048, 252579084)
               s = (50462976, 117835012, 185207048, 252579084)
             }
             h = {
               u = (256, 770, 1284, 1798, 2312, 2826, 3340, 3854)
               s = (256, 770, 1284, 1798, 2312, 2826, 3340, 3854)
             }
             b = {
               u = (0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f)
               s = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)
             }
             q = {
               u = (20011376718272490338853433276725592320)
               s = (20011376718272490338853433276725592320)
             }
           }

(and found #107864 along the way)

SVE is still not working because the initial read fails due to the > 128 bit fallback issue.