[Dwarf-Discuss] Corner-cases with bitfields

[Michael Eager]

On 5/6/22 10:11, Lancelot SIX via Dwarf-Discuss wrote:
> Dear all,
> 
> During our work on debugging support of compute workloads on AMDGPU[1],
> we (at AMD) have been seeing two cases regarding description of
> bitfields in DWARF for which we do not find definitive answers in the
> DWARF documentation.  For those cases, when experiencing with usual CPU
> targets we observe different behaviors on different toolchains.  As a
> consequence, we would like to discuss those points here to gather
> feedbacks.  If deemed necessary, we will submit a formal clarification
> issue to the dwarf committee.
> 
> Both of the cases we present below impact how arguments are passed
> during function calls in the ABI for at least our target (AMDGPU).
> However, the debug information available to the debugger does not give
> enough information to decide how to handle the type and the spec does
> not really say what debug information should be generated to properly
> describe those cases.  Also note that in both case, the DWARF
> information we have is sufficient to describe the memory layout of the
> types.
> 
> 1 - Bitfield member with a size matching its underlying type:
> 
> The first point we would like to discuss is the one of  bitfield members
> whose sizes match their underlying type.  Let's consider the following
> example:
> 
>       struct Foo
>       {
>         char a :?8;
>         char b : 8;
>       };
> 
> If we compile such example with GCC it will add the `DW_AT_bit_size` and
> `DW_AT_bit_offset` attributes to the `a` and `b` DIEs.
> 
> Clang on the other hand will not produce those attributes.

Since the specified bit size and the underlying type size are the same,
it would appear to me that specifying DW_AT_bit_size is redundant.

DW_AT_bit_offset was defined in DWARF Version 3 and 4, but has been
deprecated in DWARF Version 5.  See Section 5.7.6,
DW_AT_data_member_location and DW_AT_data_bit_offset.

> On the debugger side, GDB currently considers a struct member as being
> packed (i.e. part of a bitfield) if it has the `DW_AT_bit_size`
> attribute present and is non-0.  Therefore, GDB will "understand"
> what GCC produces, but not what Clang produces.

What is the difference in the layout for
   struct { char a; char b; } X;
and
   struct { char a:8; char b:8; } Y;

I would have to review the ISO C standard in detail, but I believe that
these are equivalent declarations.  In both structs, a is at byte offset
0 and b is at offset 1.

What is the difference in the DWARF description?

> What Clang does seems to be a reasonable thing to do if one is only
> interested in the memory layout of the type.  This however is not
> sufficient in our case to decide how to handle such type when
> placing/inspecting arguments in registers in the context of function
> calls. In our ABI, bitfield members are passed packed together, while
> two chars in a struct would be placed in separate registers.

It's not my position to critique an ABI, but this seems to require
additional packing and unpacking of char data.  Why not pack all struct
data into a minimum number of registers?  Or place all containing
entities in separate registers?

> To clarify this situation, it would be helpful that a producer always
> includes the DW_AT_bit_size attribute for bit field, which the standard
> does not suggest nor require.

DWARF is a permissive standard, which means that at times there may be
different ways of describing the same source code.  DWARF is unlikely to
require that one description is prescribed and the other proscribed.

> 
> 2 - Unnamed zero sized bitfield
> 
> Another case we met is related to unnamed fields with a size of 0 bits.
> Such field is defined in the c++ standard as (in 9.6 Bit-Fields):
> 
>   > As a special case, an unnamed bit-field with a width of zero
>   > specifies alignment of the next bit-field at an allocation unit
>   > boundary
> 
> If we now consider an extended version of our previous example:
> 
>       struct Foo
>       {
>         char a : 8;
>         char : 0;
>         char b :?8,
>       };
> 
> Neither GCC nor Clang give any information about the unnamed bitfield.
> As for the previous case, the presence of such field impacts how
> arguments are passed during function calls on our target, leaving the
> debugger unable to properly decide how to handle such cases.

The unnamed field is not accessible by any user code and, as the ISO C
standard describes, is only to insure that the following declarations
are aligned on a specific boundary which is associated with the type.

Other than forcing the alignment of following declarations, the :0
declaration has no other effect.

> As for the previous case, both compilers can properly describe Foo's
> memory layout using DW_AT_bit_offset.

Not that I agree with this contention, but DW_AT_bit_offset has been
deprecated.

> It seems that such 0-sized field also has impact on ABI on other targets
> such as armv7hl and aarch64 as discussed in [2].  Should the DWARF
> specification give some guidance on how to handle such situation?

As mentioned in [2], in the x86-64 ABI "zero width bitfields
are now ignored for both C and C++".  Perhaps that should be
the case for all ABIs.

It seems to me that this usage of :0 bitfields to indicate some
difference in struct layout (although I remain unclear what) does not
follow either the ISO C or C++ standards.

> 
> All thoughts on those cases are welcome.
> 
> Best,
> Lancelot SIX.
> 
> [1] https://llvm.org/docs/AMDGPUUsage.html
> [2] https://www.mail-archive.com/gcc at gcc.gnu.org/msg97797.html
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> 

-- 
Michael Eager