> "Simon" == Simon Marchi writes:
Simon> Just to make sure I understand, can you clarify how
Simon> DW_AT_data_member_location and DW_AT_bit_offset are used in this
Simon> case? In particular, which one is constant and which one is an
Simon> evaluated expression?
Dynamic DW_AT_data_member_l
Consider the appended Ada program. Here, the offset of "Another_Field"
is a non-constant number of bits from the start of the object.
I think there is no way to represent this in DWARF 5. Section 5.7.6,
page 119 says:
For a DW_AT_data_bit_offset attribute, the value is an integer
consta
> "John" == John DelSignore writes:
John> Is the discriminant value always a constant? Perhaps DWARF should say,
John> "The value of this attribute is of class constant." Table 2.3 defines
John> attribute class constant as, "One, two, four, eight or sixteen bytes
John> of uninterpreted data,
This comes from a Rust bug:
https://github.com/rust-lang/rust/issues/125147
DW_AT_discr_value (section 5.7 page 123) says:
The variant entry may have a DW_AT_discr_value attribute whose value
represents the discriminant value selecting this variant. The value
of this attribute is enc
> "Jakub" == Jakub Jelinek writes:
Jakub> DW_LANG_Ada950x000d 1
Jakub> I admit I know nothing about Ada (CCing Tom if he can clarify), but I'd
find it
Jakub> unexpected if Ada 83/95 defaulted to lower bound 1 and Ada 2005/2012 all
of
Jakub> sudden switched to lower bound 0.
In Ada, t
Tom> However, the completeness property is probably more important for
Tom> by-name indices, where you don't want a single typo to destroy whatever
Tom> performance gain you get from an index.
Mark> That depends on whether you assume bad addresses won't normally happen
Mark> and won't cause regene
Mark> To make it possible to quickly see whether an address (range) is covered
Mark> by an ELF file containing DWARF information two proposals were made:
I finally read through this thread.
Cary> I think it's fine for a consumer to first assume that the
Cary> .debug_aranges table is complete, but
Jakub> That's strange, for Fortran arrays GCC emits DW_OP_push_object_address
Jakub> heavily.
AFAICT it's never come "seriously" to anybody's attention.
Looking at bugzilla I do see:
https://sourceware.org/bugzilla/show_bug.cgi?id=8041
Can you send me a test case off list? It can't use Fortran
Pierre-Marie> I tried to look at the implementation of
Pierre-Marie> DW_OP_push_object_address in GDB, but it looks like it's
Pierre-Marie> not implemented yet. What do you think about its expected
Pierre-Marie> behavior? And if I cannot use this operation for such
Pierre-Marie> array bound express
> "Michael" == Michael Eager writes:
Michael> Gdb has the definition TARGET_CHAR_BIT which defines the number of
Michael> bits in a char (aka byte) on the target architecture. It may not
Michael> be taking this into account with address arithmetic or memory access.
My impression is that TAR
10 matches
Mail list logo
