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
debugge
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 her
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
> > AB
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
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
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 you
> 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
On 2022-05-06 21:08, Todd Allen via Dwarf-Discuss wrote:
> 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,
>
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 repre
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
tha
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
>
> 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
12 matches
Mail list logo
