Re: [RFA/DWARF] constant class of DW_AT_high_pc is offset for version >=4 only.

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2014-02-19 at 08:23 +0100, Joel Brobecker wrote:
> So, overall, the plan now is to adjust version #2 in the following
> ways:
>   - Add a comment in the function documentation explaining that
>     this is to help trying to read broken DWARF;
>   - Add a complaint inside the function when the attribute has
>     the wrong format
> The generalized usage of the new function is maintained.

Sounds like a good plan.

> > > > Note that this might break for DWARF5. See http://dwarfstd.org/ShowIssue.php?issue=120719.1
> > > 
> > > Interesting. I am curious why you would handle this attribute as
> > > an offset even when the value is encoded in address form?
> > 
> > As Doug said, it is a space saving (offsets are often small) and it
> > saves a relocation (linkers have to resolve all DW_FORM_addr values and
> > they add up).
> 
> I was wondering why we don't "simply" require a constant format in
> this case, instead of allowing both formats.

DWARF in general seems to prefer only extensions, not deprecation of old
supported ways of doing things. So that DWARFvX is (mostly) valid
DWARFvX+1.

In the case of DW_AT_high_pc you could in principle support only one way
to do it, since it is always used in combination with DW_AT_low_pc as a
pair of attributes. So in that case only supporting an offset in
constant form is fine. But in the case of DW_AT_entry_pc the offset in
constant form variant only makes sense if there is a DW_AT_ranges or
DW_AT_low_pc attribute that gives the "base address". But in theory
(though very unlikely) DW_AT_entry_pc could occur without either of
those other attributes present. So I think also supporting the address
form is still required there.

Cheers,

Mark