Incomplete debug information for _BitInt(N) when N differs from store size

[dstenb]

Sorry in case there already is a ticket for this. I have tried to dig to understand the history of this looking back at _ExtInt, and have searched for tickets that cover this issue for either _ExtInt or _BitInt, but haven't found one.

Currently Clang emits base types for _BitInt(N) types with the name unsigned _BitInt or _BitInt, with the DW_AT_byte_size value being the store size. There is no information regarding the number of bits, N, which leaves the debugger unable to (at least) properly print negative values when N differs from the store size, as it then prints a DW_AT_byte_size-sized value including the zero-valued padding bits.

Example:

_BitInt(15) a = -1wb;
_BitInt(16) b = -1wb;
int main() { return 0; }

Running:

$ build/bin/clang -g bitint.c -o bitint.out

gives:

0x00000023:   DW_TAG_variable
                DW_AT_name      ("a")
                DW_AT_type      (0x0000002e "_BitInt")
                DW_AT_external  (true)
                DW_AT_decl_file ("/upstream/llvm-project/bitint.c")
                DW_AT_decl_line (1)
                DW_AT_location  (DW_OP_addrx 0x0)

0x0000002e:   DW_TAG_base_type
                DW_AT_name      ("_BitInt")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x02)

0x00000032:   DW_TAG_variable
                DW_AT_name      ("b")
                DW_AT_type      (0x0000002e "_BitInt")
                DW_AT_external  (true)
                DW_AT_decl_file ("/upstream/llvm-project/bitint.c")
                DW_AT_decl_line (2)
                DW_AT_location  (DW_OP_addrx 0x1)

LLDB (trunk):

$ build/bin/lldb bitint.out
(lldb) b main
Breakpoint 1: where = bitint.out`main + 11 at bitint.c:3:14, address = 0x000000000000069b
(lldb) run
Process 158466 launched: '/upstream/llvm-project/bitint.out' (x86_64)
Process 158466 stopped
* thread #1, name = 'bitint.out', stop reason = breakpoint 1.1
    frame #0: 0x000055555555469b bitint.out`main at bitint.c:3:14
   1    _BitInt(15) a = -1wb;
   2    _BitInt(16) b = -1wb;
-> 3    int main() { return 0; }
(lldb) p a
(short) 32767
(lldb) p b
(short) -1

GDB (version 11.1, I have not tried a latter version yet):

(gdb) b main
Breakpoint 1 at 0x69b: file bitint.c, line 3.
(gdb) run
Starting program: /upstream/llvm-project/bitint.out 

Breakpoint 1, main () at bitint.c:3
3       int main() { return 0; }
(gdb) p a
$1 = 32767
(gdb) p b
$2 = -1

The debugger must be informed in some way of the number of bits in the _BitInt, either expressed in the type itself, or we need to make sure that the locations include an explicit signed cast from the number of data bits to the store size.

Has there been any work related to this?

[llvmbot]

@llvm/issue-subscribers-debuginfo

[dstenb]

Looking in the DWARFv5 spec for base type entries, I think this would cover it:

5.1 Base Type Entries:

If the value of an object of the given type does not fully occupy the storage
described by a byte size attribute, the base type entry may also have a
DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose values
are integer constant values (see Section 2.19 on page 55). The bit size attribute
describes the actual size in bits used to represent values of the given type. The
data bit offset attribute is the offset in bits from the beginning of the containing
storage to the beginning of the value. Bits that are part of the offset are padding.
If this attribute is omitted a default data bit offset of zero is assumed.

I have made a hacky patch which extends LLVM's DIBasicType to include an extra optional data_bits attribute, which would be used in cases where the number of data bits differ from the store size: https://reviews.llvm.org/D147625

This then results in DW_AT_bit_size (and DW_AT_data_bit_offset) attributes in the type DIEs. The type names are also changed to _BitInt(N) to include the number of bits.

Not much thought has been put in the interface added in the patch; it was only a way to propagate the information from Clang to AsmPrinter in order to prototype this!

Running the example from the description gives:

0x00000023:   DW_TAG_variable
                DW_AT_name      ("a")
                DW_AT_type      (0x0000002e "_BitInt(15)")
                DW_AT_external  (true)
                DW_AT_decl_file ("/upstream/llvm-project/bitint.c")
                DW_AT_decl_line (1)
                DW_AT_location  (DW_OP_addrx 0x0)

0x0000002e:   DW_TAG_base_type
                DW_AT_name      ("_BitInt(15)")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x02)
                DW_AT_bit_size  (0x0f)

0x00000033:   DW_TAG_variable
                DW_AT_name      ("b")
                DW_AT_type      (0x0000003e "_BitInt(16)")
                DW_AT_external  (true)
                DW_AT_decl_file ("/upstream/llvm-project/bitint.c")
                DW_AT_decl_line (2)
                DW_AT_location  (DW_OP_addrx 0x1)

0x0000003e:   DW_TAG_base_type
                DW_AT_name      ("_BitInt(16)")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x02)

With GDB 11.1 this results in the 15-bit variable being correctly printed:

(gdb) b main
Breakpoint 1 at 0x69b: file bitint.c, line 3.
(gdb) run
Starting program: /upstream/llvm-project/bitint.out 

Breakpoint 1, main () at bitint.c:3
3       int main() { return 0; }
(gdb) print a
$1 = -1
(gdb) print b
$2 = -1
(gdb) ptype a
type = _BitInt(15)
(gdb) ptype b
type = _BitInt(16)

However, with LLDB it is still printed as an unsigned 16-bit value:

(lldb) b main
Breakpoint 1: where = bitint.out`main + 11 at bitint.c:3:14, address = 0x000000000000069b
(lldb) run
Process 40142 launched: '/upstream/llvm-project/bitint.out' (x86_64)
Process 40142 stopped
* thread #1, name = 'bitint.out', stop reason = breakpoint 1.1
    frame #0: 0x000055555555469b bitint.out`main at bitint.c:3:14
   1    _BitInt(15) a = -1wb;
   2    _BitInt(16) b = -1wb;
-> 3    int main() { return 0; }
(lldb) p a
(short) 32767
(lldb) p b
(short) -1

I have not tried examples with other widths in GDB yet.

[dwblaikie]

(probably not the right solution - but debuggers already understand "boolean" explicitly, for instance - which bit in the byte of storage contians the value, etc - so in theory they could be taught to understand these _bitint things, but I guess these are much less ubiquitous than boolean, so describing them in DWARF so consumers don't have to be taught about them is the right tradeoff)

Yeah, the bit_size thing seems suitable. Is that what GCC uses for these bitint things?

[dstenb]

Is that what GCC uses for these bitint things?

AFAIK, support for _BitInt has not been implemented in GCC yet. There is an open ticket last updated in October: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989.

I have not built and tried out GCC from trunk though, so I don't know if there has been some more recent work that is not covered by that ticket.

[dwblaikie]

ah, yeah, not on GCC trunk: https://godbolt.org/z/vxPof9x1o

So this _Bitint thing is purely a clang extension? Then, yeah, guess more reason that we use a DWARF encoding that's understandable without hardcoded/prior knowledge in the consumer.

[dstenb]

So this _Bitint thing is purely a clang extension? Then, yeah, guess more reason that we use a DWARF encoding that's understandable without hardcoded/prior knowledge in the consumer.

I think it originated as a clang extension (originally as _ExtInt), but it is now planned to be included in C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf.

[dstenb]

Jakub Jelinek has created a DWARF issue for adding bitint encodings: https://dwarfstd.org/issues/230529.1.html.

[OCHyams]

I had a go at this over in #164372

Note that in order to show incorrect-before and correct-after patch behaviour I had to change the reproducer to:

     1  #include <string.h>
     2
     3  int main() {
     4    _BitInt(15) a;
     5    memset(&a, 0x7f, 2);
     6    return 0;     // GDB: b 6, p a
     7  }

In GDB, on line 6, before the patch we get the value of a as $1 = 32639 and after $1 = -129. LLDB shows $1 = 32639 for both so I guess it doesn't understand this use of DW_AT_bit_size.