[Dwarf-Discuss] DW_AT_entry_pc vs DW_AT_ranges

[Mark Wielaard]

On Wed, May 02, 2012 at 01:46:54PM +0200, Mark Wielaard wrote:
> I was looking at when GCC produces a DW_AT_entry_pc attribute for a
> function DIE that has DW_AT_ranges. It always generates one for a
> DW_TAG_inlined_subprogram if the first address in the ranges represents
> the first instruction of the original subprogram that is inlined here.
> 
> This seems reasonable since in those cases the compiler knows that
> address really is the first executable instruction within the range of
> addresses as the standard describes. And it allows you to select those
> inlined_subprograms that represent all the places where you would want
> to put a breakpoint at to catch any "call" of the original subprogram
> even when inlined. If only parts of a function is inlined it won't get a
> DW_AT_entry_pc and you wouldn't select it.
> 
> So two questions about this.
> 
> 1) Since GCC only emits DW_AT_entry_pc for DW_TAG_subroutine if the
> first ranges address corresponds to the instructions of the original
> function entry point some consumers now seem to depend on selecting
> inlined subprograms that way to pick up all inlined copies that
> represent a "call" of the original subprogram. Is there a better way to
> express this relationship?
> 
> 2) That the first DW_AT_ranges address equals the DW_AT_entry_pc address
> seems to be a common occurrence. It makes sense the compiler outputs the
> ranges in low-to-high address order. But that means the encoding of
> DW_AT_entry_pc as a relocatable address is somewhat inefficient. Would
> it make sense to add a special form for this situation? Define that
> DW_AT_entry_pc can either be of class address or flag. And if it is of
> class flag, then when present the address of DW_AT_entry_pc corresponds
> to the first address found in DW_AT_ranges.

I got one off-list reply to the second suggestion, adding that having
a constant form could also be added so it is an offset relative to the
first pc of the range.

Does it make sense to write up an proposal for the second part?
I could also hack up a GCC patch for it, to better show the impact
if that would help.

And anybody got an idea on how the more precisely express the
relationship described in the first question?

Thanks,

Mark