Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On 5/10/22 02:15, Pedro Alves via Dwarf-Discuss wrote: But still, at the language level, the types ARE different. And DWARF is also about language source to machine code mapping. C/C++ don't let you take the address of a bitfield, for example, so it's possible type expressions in the debugger that behave differently depending on what the DWARF described. In a previous email in this thread, I mentioned that I thought "char a;" and "char a:8" in a struct were equivalent. I forgot about the restriction on using the address operator, mentioned in ISO C Sect. 6.5.3.2 (at least, in the old copy I have). They are not equivalent. Thanks for reminding me. So in my view, you'd want a producer to always indicate that the field is a bitfield somehow, even if the memory layout wouldn't change, i.e., regardless of ABI. Maybe we can convince Clang folks of the same as GCC, that certainly sounds simpler, but I figured that maybe there would be agreement that the spec itself should be tweaked in this direction, if every producer would come to the same conclusion. It's better to propose a change to the DWARF Standard. You can submit a proposal on the Public Comment page: https://dwarfstd.org/Comment.php. Describe the issue briefly and, if possible, please specify the change to the wording of the DWARF Standard that would think appropriate. -- Michael Eager ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On 2022-05-09 22:41, Robinson, Paul wrote:
>> Pedro Alves wrote:
>> On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote:
>>> So my suggestion is to file a bug report with CLANG, requesting they
>> correct their DWARF output to reflect all details needed
>>> by your language.
>>
>> An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member
>> Entries, page 119):
>>
>> "If the size of a data member is not the same as the size of the type
>> given for the
>>
>> ^^
>> ^^^
>> data member, the data member has either a DW_AT_byte_size or a
>> ^^^
>> DW_AT_bit_size attribute whose integer constant value (see Section 2.19
>> on
>> page 55) is the amount of storage needed to hold the value of the data
>> member."
>>
>> Note the part I underlined. In Lancelot's case, the size of the data
>> member
>> IS the same as the size of the type given for the data member. So Clang
>> could well pedantically
>> claim that they _are_ following the spec. Shouldn't the spec be clarified
>> here?
>
> What the spec says is that a producer isn't _required_ to emit the
> DW_AT_bit_size attribute. But, given that DWARF is a permissive
> standard, the producer is certainly _allowed_ to emit the attribute.
> If this is a hint that the target debugger will understand, regarding
> the ABI, it seems okay to me for the producer to do that.
>
>> This then raises the question of whether a debugger can assume that the
>> presence of a DW_AT_bit_size
>> attribute indicates that the field is a bit field at the C/C++ source
>> level. GDB is assuming that
>> today, as there's really no other way to tell, but I don't think the spec
>> explicitly says so.
>
> GDB is choosing to make that interpretation, which it's allowed to do.
> The DWARF spec just doesn't promise that interpretation is correct.
OOC, do you know of any consumer that makes a different interpretation?
>
> You can propose to standardize that interpretation by filing an issue
> with the DWARF committee at https://dwarfstd.org/Comment.php and it might
> or might not become part of DWARF v6.
We're just here in open dwarf-discuss list discussing potential approaches
and hearing from experience and guidance of/from others before deciding whether
an issue should be filed at all, and if submitting an issue is needed, then
which approach or approaches could have better chances of going through.
> It might be tricky because you'd
> be generalizing something very specific to your environment.
I actually don't see why is this specific to one environment. See below.
>
> You can also, separately, try to get Clang to emit the DW_AT_bit_size
> attribute in these cases for the AMDGPU target(s). This seems more
> likely to work, especially as there's an ABI requirement involved, and
> (given that GDB makes this interpretation) I assume gcc already does this.
GCC emits DW_AT_bit_size for bitfields for all targets and ABIs AFAICT. At:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dwarf2out.cc;h=5681b01749add28c52666b41e44cbbc239f7204a;hb=HEAD#l25011
we have:
if (DECL_BIT_FIELD_TYPE (decl))
{
add_byte_size_attribute (decl_die, decl);
add_bit_size_attribute (decl_die, decl);
add_bit_offset_attribute (decl_die, decl);
}
I don't see why this needs to be restricted to some ABIs. I mean, with
DWARF emitted by GCC, with code like this:
struct Foo
{
char a : 8;
char b : 8;
};
Foo foo;
int main () {}
you get, on x86:
(gdb) ptype foo
type = struct Foo {
char a : 8;
char b : 8;
}
and with DWARF emitted by Clang, you get:
(gdb) ptype foo
type = struct Foo {
char a;
char b;
}
Sure, on x86, the bitfield vs non-bitfield types are laid out in memory the
same. But still, at the language level, the types ARE different. And DWARF is
also about language source to machine code mapping. C/C++ don't let you take
the
address of a bitfield, for example, so it's possible type expressions in the
debugger that behave differently depending on what the DWARF described.
>From the perspective of GDB, IMO, this is a bug, even on x86.
So in my view, you'd want a producer to always indicate that the field
is a bitfield somehow, even if the memory layout wouldn't change, i.e.,
regardless of ABI.
Maybe we can convince Clang folks of the same as GCC, that certainly sounds
simpler,
but I figured that maybe there would be agreement that the spec itself should
be tweaked
in this direction, if every producer would come to the same conclusion.
Pedro Alves
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On Mon, May 09, 2022 at 04:09:59PM -0700, Michael Eager wrote: > On 5/9/22 16:00, Todd Allen via Dwarf-Discuss wrote: > > I suppose, if you didn't want to submit an issue, another solution would be > > to > > require the necessary tags & attributes in the ABI itself. We already > > expect > > ABI documents to provide things like register values, CFI initial values, > > and > > some more esoteric stuff (augmentations, non-standard endianity & isa). An > > ABI > > that required descriptions in ABI-specific situations like these two seems > > reasonable to me. And it places no burden on compilers for other ABI's. > > This creates the situation where there are two definitions for a DWARF > attribute, one in an ABI and a different one in the DWARF Spec. We want to > avoid situations where one producer says "I'm following DWARF" and another > "I'm following the ABI". That makes interoperability difficult. > > The information you mention in an ABI is not in the DWARF Spec. > I don't know that it's quite that bad. The ABI could say that DW_AT_bit_size *also* implies that the field is a bit field for ABI purposes. That doesn't change the meaning from the DWARF specification; it merely adds to it. Mind you, I think an explicit DW_AT_bit_field (or something like that) is better. Also, while the DWARF standard is intentionally permissive, an ABI need not be. They could mandate either of the above solutions, and also mandate descriptions of anonymous 0-sized fields. (Unless there's a better, more direct description for that case.) -- Todd Allen Concurrent Real-Time ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On 5/9/22 16:00, Todd Allen via Dwarf-Discuss wrote: I suppose, if you didn't want to submit an issue, another solution would be to require the necessary tags & attributes in the ABI itself. We already expect ABI documents to provide things like register values, CFI initial values, and some more esoteric stuff (augmentations, non-standard endianity & isa). An ABI that required descriptions in ABI-specific situations like these two seems reasonable to me. And it places no burden on compilers for other ABI's. This creates the situation where there are two definitions for a DWARF attribute, one in an ABI and a different one in the DWARF Spec. We want to avoid situations where one producer says "I'm following DWARF" and another "I'm following the ABI". That makes interoperability difficult. The information you mention in an ABI is not in the DWARF Spec. -- Michael Eager ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On 5/9/22 13:18, Pedro Alves via Dwarf-Discuss wrote: An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member Entries, page 119): "If the size of a data member is not the same as the size of the type given for the ^ data member, the data member has either a DW_AT_byte_size or a ^^^ DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on page 55) is the amount of storage needed to hold the value of the data member." Note the part I underlined. In Lancelot's case, the size of the data member IS the same as the size of the type given for the data member. So Clang could well pedantically claim that they _are_ following the spec. Shouldn't the spec be clarified here? This then raises the question of whether a debugger can assume that the presence of a DW_AT_bit_size attribute indicates that the field is a bit field at the C/C++ source level. GDB is assuming that today, as there's really no other way to tell, but I don't think the spec explicitly says so. DWARF tries to avoid having one piece of information with a clear description imply or suggest something else, with perhaps different implications for different people. It seems to me that other languages (Ada?) have variables which do not fill the data type, so it would be reasonable for them to have a DW_AT_bit_size which is different from the data type size, yet not be a bit field. As currently described, DW_AT_bit_size only describes the size of the data, nothing more, and only when that cannot be determined from the size of the base type. If you want to change the definition to say that it has an additional meaning (describing a bit field with a certain size), submit an issue. Alternately, Todd suggested a new flag to identify a bit field. -- Michael Eager ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
On Mon, May 09, 2022 at 09:41:03PM +, Dwarf Discussion wrote: > > Pedro Alves wrote: > > On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote: > > > So my suggestion is to file a bug report with CLANG, requesting they > > correct their DWARF output to reflect all details needed > > > by your language. > > > > An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member > > Entries, page 119): > > > > "If the size of a data member is not the same as the size of the type > > given for the > > > > ^^ > > ^^^ > > data member, the data member has either a DW_AT_byte_size or a > > ^^^ > > DW_AT_bit_size attribute whose integer constant value (see Section 2.19 > > on > > page 55) is the amount of storage needed to hold the value of the data > > member." > > > > Note the part I underlined. In Lancelot's case, the size of the data > > member > > IS the same as the size of the type given for the data member. So Clang > > could well pedantically > > claim that they _are_ following the spec. Shouldn't the spec be clarified > > here? > > What the spec says is that a producer isn't _required_ to emit the > DW_AT_bit_size attribute. But, given that DWARF is a permissive > standard, the producer is certainly _allowed_ to emit the attribute. > If this is a hint that the target debugger will understand, regarding > the ABI, it seems okay to me for the producer to do that. > > > This then raises the question of whether a debugger can assume that the > > presence of a DW_AT_bit_size > > attribute indicates that the field is a bit field at the C/C++ source > > level. GDB is assuming that > > today, as there's really no other way to tell, but I don't think the spec > > explicitly says so. > > GDB is choosing to make that interpretation, which it's allowed to do. > The DWARF spec just doesn't promise that interpretation is correct. > > You can propose to standardize that interpretation by filing an issue > with the DWARF committee at https://dwarfstd.org/Comment.php and it might > or might not become part of DWARF v6. It might be tricky because you'd > be generalizing something very specific to your environment. > > You can also, separately, try to get Clang to emit the DW_AT_bit_size > attribute in these cases for the AMDGPU target(s). This seems more > likely to work, especially as there's an ABI requirement involved, and > (given that GDB makes this interpretation) I assume gcc already does this. > Lancelot, I suppose, if you didn't want to submit an issue, another solution would be to require the necessary tags & attributes in the ABI itself. We already expect ABI documents to provide things like register values, CFI initial values, and some more esoteric stuff (augmentations, non-standard endianity & isa). An ABI that required descriptions in ABI-specific situations like these two seems reasonable to me. And it places no burden on compilers for other ABI's. -- Todd Allen Concurrent Real-Time ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
> Pedro Alves wrote: > On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote: > > So my suggestion is to file a bug report with CLANG, requesting they > correct their DWARF output to reflect all details needed > > by your language. > > An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member > Entries, page 119): > > "If the size of a data member is not the same as the size of the type > given for the > > ^^ > ^^^ > data member, the data member has either a DW_AT_byte_size or a > ^^^ > DW_AT_bit_size attribute whose integer constant value (see Section 2.19 > on > page 55) is the amount of storage needed to hold the value of the data > member." > > Note the part I underlined. In Lancelot's case, the size of the data > member > IS the same as the size of the type given for the data member. So Clang > could well pedantically > claim that they _are_ following the spec. Shouldn't the spec be clarified > here? What the spec says is that a producer isn't _required_ to emit the DW_AT_bit_size attribute. But, given that DWARF is a permissive standard, the producer is certainly _allowed_ to emit the attribute. If this is a hint that the target debugger will understand, regarding the ABI, it seems okay to me for the producer to do that. > This then raises the question of whether a debugger can assume that the > presence of a DW_AT_bit_size > attribute indicates that the field is a bit field at the C/C++ source > level. GDB is assuming that > today, as there's really no other way to tell, but I don't think the spec > explicitly says so. GDB is choosing to make that interpretation, which it's allowed to do. The DWARF spec just doesn't promise that interpretation is correct. You can propose to standardize that interpretation by filing an issue with the DWARF committee at https://dwarfstd.org/Comment.php and it might or might not become part of DWARF v6. It might be tricky because you'd be generalizing something very specific to your environment. You can also, separately, try to get Clang to emit the DW_AT_bit_size attribute in these cases for the AMDGPU target(s). This seems more likely to work, especially as there's an ABI requirement involved, and (given that GDB makes this interpretation) I assume gcc already does this. --paulr ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
Hi, (using my subscribed gmail address until my main address, CCed, is approved to also join the list.) On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote: > It seems to me that the problem here is not so much in the DWARF standard, as > in the DWARF that is produced. > > The DWARF representation generally serves to capture all the semantic > information needed to properly represent > the source program. In the example discussed here it appears that GCC does > that (by including the bit field information) and > CLANG does not (by erroneously omitting the bit field information). > > It is probably the case that in most languages char a; and char a:8; are > semantically equivalent IN ALL RESPECTS. > For such languages,the producer/compiler is probably justified (or at least > can be forgiven) for omitting the bit field information > for char a:8. But evidently for "AMDGP-Lang" the two are not the same--while > the storage layout may be the same, other > subtle but critical aspects of the language and its ABI are quite different > in the two cases. Agreed so far. > > One might have a philosophical debate about whether this difference is > appropriate or not. But as Lancelot says, the ABI is > what it is and any change is unlikely nearterm so such a debate is moot. The > only issue is whether DWARF is able to > convey the needed information. I think DWARF is able, if only the > producer/compiler would do it properly. > Agreed. > So my suggestion is to file a bug report with CLANG, requesting they correct > their DWARF output to reflect all details needed > by your language. An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member Entries, page 119): "If the size of a data member is not the same as the size of the type given for the ^ data member, the data member has either a DW_AT_byte_size or a ^^^ DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on page 55) is the amount of storage needed to hold the value of the data member." Note the part I underlined. In Lancelot's case, the size of the data member IS the same as the size of the type given for the data member. So Clang could well pedantically claim that they _are_ following the spec. Shouldn't the spec be clarified here? This then raises the question of whether a debugger can assume that the presence of a DW_AT_bit_size attribute indicates that the field is a bit field at the C/C++ source level. GDB is assuming that today, as there's really no other way to tell, but I don't think the spec explicitly says so. Pedro Alves ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
It seems to me that the problem here is not so much in the DWARF standard,
as in the DWARF that is produced.
The DWARF representation generally serves to capture all the semantic
information needed to properly represent
the source program. In the example discussed here it appears that GCC does
that (by including the bit field information) and
CLANG does not (by erroneously omitting the bit field information).
It is probably the case that in most languages char a; and char a:8; are
semantically equivalent IN ALL RESPECTS.
For such languages,the producer/compiler is probably justified (or at least
can be forgiven) for omitting the bit field information
for char a:8. But evidently for "AMDGP-Lang" the two are not the
same--while the storage layout may be the same, other
subtle but critical aspects of the language and its ABI are quite different
in the two cases.
One might have a philosophical debate about whether this difference is
appropriate or not. But as Lancelot says, the ABI is
what it is and any change is unlikely nearterm so such a debate is moot.
The only issue is whether DWARF is able to
convey the needed information. I think DWARF is able, if only the
producer/compiler would do it properly.
So my suggestion is to file a bug report with CLANG, requesting they
correct their DWARF output to reflect all details needed
by your language.
Ron Brender
On Mon, May 9, 2022 at 7:13 AM Lancelot SIX via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Hi,
>
> Thanks for the feedback.
>
> >
> > It sounds like your ABI is basing its decision on a boolean: is the
> field a bit
> > field or not. And you're trying to deduce this from DW_AT_bit_offset.
> Perhaps
> > a better solution would be to make this explicit in the DWARF, some new
> > DW_AT_bitfield flag. There's very little that the DWARF standard can do
> to
> > mandate such an attribute. (Permissive standard yadda yadda.) But if
> it's
> > necessary for debuggers to work correctly in a given ABI, compilers
> should be
> > well-motivated to produce it when generating code for that ABI.
> >
> > [...]
> >
> > I'm agreeing with Michael that describing the unnamed bitfield seems
> dubious.
> > If it does impact the ABI, I'm wondering if that impact is indirect:
> that is,
> > the presence of this 0-width bit field changes an attribute of the next
> field,
> > and that attribute is responsible for difference in the behavior. If
> so, is
> > there any way other than a 0-width bit field to cause the same
> behavior? This
> > might be another case where describing the attribute that's directly
> responsible
> > might be better.
> >
> > --
> > Todd Allen
> > Concurrent Real-Time
>
> Indeed, two flags can conceptually provide sufficient information to the
> debugger. I am not aware of a situation not involving the 0-wide
> unnamed bitfield which can trigger the same behavior. The unnamed
> field is not really important in itself, only the effect it has on the
> following field is.
>
> To help the discussion, let me use a concrete example and how it is
> handled in our ABI as it is today. Lets suppose you have a struct like:
>
> struct Foo {
> int fill[4];
> char c1;
> char c2 : 8;
> char c3 : 8;
> char : 0;
> char c4 : 8;
> char c5 : 8;
> };
>
> If we have a function returning a value of such type by value, the
> return value would be passed in registers back to the caller (the
> situation would be similar when calling a function with a Foo
> parameter). In our architecture, the registers used are 32 bit wide*
> and called Vx, x being the register number (*this is a simplified
> model sufficient for the current discussion).
>
> In this example, the `fill` member is not really important. It is only
> there because a value under 64 bits would otherwise be returned packed.
>
> So suppose that we stop a program just after returning from a function
> returning such value. This is what a debugger such as GDB would do when
> using the `finish` command. To figure out the value returned by the
> function, the debugger needs to inspect the debuggee's registers based
> on the function's return type.
>
> In this situation, the ABI conceptually decomposes the struct into its
> member and places each member in a register. Bitfield members are
> considered as packed into one member. The result is:
>
>
> +---+---+---+---+
> | V0| V1| V2| V3
> |
> | fill[0] | fill[1] | fill[2] |
> fill[3] |
>
> +---+---+---+---+
> +---+---+---+
> | V4| V5| V6|
> | | c1 | xxx | c3 | c2 | xxx | c5 | c4 |
> +---+---+---+
>
> If we do not specify the `:
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
Hi,
Thanks for the feedback.
>
> It sounds like your ABI is basing its decision on a boolean: is the field a
> bit
> field or not. And you're trying to deduce this from DW_AT_bit_offset.
> Perhaps
> a better solution would be to make this explicit in the DWARF, some new
> DW_AT_bitfield flag. There's very little that the DWARF standard can do to
> mandate such an attribute. (Permissive standard yadda yadda.) But if it's
> necessary for debuggers to work correctly in a given ABI, compilers should be
> well-motivated to produce it when generating code for that ABI.
>
> [...]
>
> I'm agreeing with Michael that describing the unnamed bitfield seems dubious.
> If it does impact the ABI, I'm wondering if that impact is indirect: that is,
> the presence of this 0-width bit field changes an attribute of the next field,
> and that attribute is responsible for difference in the behavior. If so, is
> there any way other than a 0-width bit field to cause the same behavior? This
> might be another case where describing the attribute that's directly
> responsible
> might be better.
>
> --
> Todd Allen
> Concurrent Real-Time
Indeed, two flags can conceptually provide sufficient information to the
debugger. I am not aware of a situation not involving the 0-wide
unnamed bitfield which can trigger the same behavior. The unnamed
field is not really important in itself, only the effect it has on the
following field is.
To help the discussion, let me use a concrete example and how it is
handled in our ABI as it is today. Lets suppose you have a struct like:
struct Foo {
int fill[4];
char c1;
char c2 : 8;
char c3 : 8;
char : 0;
char c4 : 8;
char c5 : 8;
};
If we have a function returning a value of such type by value, the
return value would be passed in registers back to the caller (the
situation would be similar when calling a function with a Foo
parameter). In our architecture, the registers used are 32 bit wide*
and called Vx, x being the register number (*this is a simplified
model sufficient for the current discussion).
In this example, the `fill` member is not really important. It is only
there because a value under 64 bits would otherwise be returned packed.
So suppose that we stop a program just after returning from a function
returning such value. This is what a debugger such as GDB would do when
using the `finish` command. To figure out the value returned by the
function, the debugger needs to inspect the debuggee's registers based
on the function's return type.
In this situation, the ABI conceptually decomposes the struct into its
member and places each member in a register. Bitfield members are
considered as packed into one member. The result is:
+---+---+---+---+
| V0| V1| V2| V3
|
| fill[0] | fill[1] | fill[2] | fill[3]
|
+---+---+---+---+
+---+---+---+
| V4| V5| V6|
| | c1 | xxx | c3 | c2 | xxx | c5 | c4 |
+---+---+---+
If we do not specify the `: 8`s, then each char is allocated its own
register (so c1 in V4, c2 in V5, and so on until c5 in V8).
If we remove the unnamed 0-sized field, then c2, c3, c4, c5 are all
packed into V5.
My main problem today is that the debugger needs to figure out how such
type is passed as an argument or returned from a function, while basing
its decision solely on the description of the Foo type in the debugging
information.
Unfortunately, as far I know, the debugging information does not allow
me to differentiate the Foo type as written above to a type without the
`: 8` or without the unnamed field. As a consequence, the debugger will
in some situations make wrong decisions. Also note that such difference
would not change how a value of type Foo is laid out in memory, only the
decomposition into registers for function call purposes is impacted.
I do not claim the ABI is flawless, good or bad in any way. It is the
way it is and for the time being it is going to remain stable.
Nevertheless, if we want to provide good debugging experience for our
target (which we do), we need to address those cases in a way or
another (two flags are good candidates).
I hope this example helps to illustrate the limitations we are
currently facing.
Best,
Lancelot.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields
>
> 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.
>
> 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 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.
>
> 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.
>
It sounds like your ABI is basing its decision on a boolean: is the field a bit
field or not. And you're trying to deduce this from DW_AT_bit_offset. Perhaps
a better solution would be to make this explicit in the DWARF, some new
DW_AT_bitfield flag. There's very little that the DWARF standard can do to
mandate such an attribute. (Permissive standard yadda yadda.) But if it's
necessary for debuggers to work correctly in a given ABI, compilers should be
well-motivated to produce it when generating code for that ABI.
> 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.
>
I'm agreeing with Michael that describing the unnamed bitfield seems dubious.
If it does impact the ABI, I'm wondering if that impact is indirect: that is,
the presence of this 0-width bit field changes an attribute of the next field,
and that attribute is responsible for difference in the behavior. If so, is
there any way other than a 0-width bit field to cause the same behavior? This
might be another case where describing the attribute that's directly responsible
might be better.
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
