On 5/10/22 04:10, Pedro Alves via Dwarf-Discuss wrote:
On 2022-05-06 18:11, Lancelot SIX via Dwarf-Discuss wrote:
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.
As for the previous case, both compilers can properly describe Foo's
memory layout using DW_AT_bit_offset.
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?
All thoughts on those cases are welcome.
In DWARF 5, we have:
"5.7.6
Data Member Entries
A data member (as opposed to a member function) is represented by a
debugging information entry with the tag DW_TAG_member. The member
entry for a named member has a DW_AT_name attribute whose value is a
null-terminated string containing the member name. If the member entry
describes an anonymous union, the name attribute is omitted or the value of the
attribute consists of a single zero byte."
I didn't find anything that would prevent a producer from emitting an
unnamed bit-field member. Ignoring the 0-size special case for the moment,
neither GCC nor Clang emit the unnamed bit-field in this case either:
struct Foo
{
char a : 8;
char : 8;
char b : 8;
};
I suppose you could call it QoI to emit an unnamed field for this unnamed
bit-field,
in the same vein of what I mentioned earlier about making it possible for the
debugger to
reconstruct the original type (a debugger could infer the size of the unnamed
bit-field
from the gap, but not its declared type). I didn't find wording in the spec
that
would prevent it.
Nothing in DWARF would seem to prohibit generating a unnamed field, nor
would anything require it. It's QoI; with it a debugger can print an
field without a name, without you cannot. (It's possible that a
debugger might not expect a zero-size field, but that, too, is QoI.)
From that angle, unnamed zero-sized bit-fields could also be emitted, ISTM
that it's
technically possible to describe it with current DWARF, though,
consumer-implementation-wise,
a consumer may need to be able to distinguish "no DW_AT_bit_size present" vs
"DW_AT_bit_size present and value is 0". Anyone see an issue with making that
distinction
DWARF-spec wise? Could that result in ambiguities somewhere? I don't think
that GDB makes
such a distinction currently, I think internally "bit size == 0" means not a
bit field,
but that would be changed, of course, it's implementation detail.
A proposal for DWARF to require DW_AT_bit_size for all bit fields would
address this.
For some reason (maybe because of the weird "single zero byte" special case?),
the
wording above from 5.7.6 describes what to do with anonymous unions, kind of
giving
the impression that it could also specify what is expected with other unnamed
fields
such as unnamed bit-fields.
That line might be tweaked to apply to all unnamed entities.
OTOH, we have "D.2.8 C/C++ Bit-Field Examples", where the spec says "Bit fields
in C and C++
typically require the use of the DW_AT_data_bit_offset and DW_AT_bit_size
attributes.".
It then goes on to give examples of big- and little-endian machines. Maybe
this chapter would
be the spot where the spec would give the example of what to do with unnamed
bit-fields
of 0 size, as _it is_ a special case described in the C++ language spec, i.e.,
has meaning
at the language level that is lost otherwise, and the D.2.8 chapter in the
DWARF spec is
specifically about C/C++.
The Appendices are not normative parts of the standard. They only offer
suggestions on how to represent various situations. Changes in how
unnamed bit fields should be described would be in the body of the
standard. (And the example could be extended.)
Or this is yet another case that people would prefer to leave things as is
DWARF-spec-wise
and we should go file bug reports with GCC and Clang?
Submit an issue to DWARF to have the standard clarified/enhanced and
file a bug report with GCC & Clang.
--
Michael Eager
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
