[Dwarf-discuss] DW_AT_ranges info generated by gcc

[Fred Fish]

On Wednesday 20 April 2005 13:07, Daniel Jacobowitz wrote:
> Think of a DIE with DW_AT_low_pc and DW_AT_high_pc as exactly
> equivalent to a DIE with DW_AT_ranges and only a single range.

Yes, that makes perfect sense.

> It seems natural to me that an outer scope which completely encloses an
> inner scope will have PC bounds completely enclosing the bounds of its
> inner scopes.  Functions already do this; it's pretty clear that the
> range information for a function should include all code associated
> with the function.

My mental picture was slightly different but I'm certainly open to
adjusting it as needed.

Consider the case where function CALLER calls function CALLEE out of
line (I.E. no inlining) then the list of PC's that are attributable to
code that implements CALLER is disjoint from the list of PC's that
implement CALLEE.  I.E. something like:

	CALLER:		A1
			A2
			A3

	CALLEE:		B1
			B2
			B3

and so the PC's associated with CALLER would be A1, A2, A3 and the PC's
for CALLEE would be B1, B2, B3.  If CALLEE is inlined into CALLER, like:

	CALLER:		A1
	CALLEE:	`	B1
			B2
			B3
			A2
			A3

I guess I would expect a range list for CALLER that was

			A1
			A2-A3

and CALLEE would be

			B1-B3

> I'm getting the impression you want no range lists to overlap.  Why?

Guess I just don't find it very intuitive that a single instruction
could be part of the code that implements a succession of nested
inlined functions when that instruction would only be associated with
one function in the absence of any inlining.

> Can you give me an example of a situation where having a PC value
> included in the ranges of multiple nested blocks is a problem?

Not as long as the code that attempts to match a PC value with the
function that generated the instruction at the PC knows to look for
the smallest inclosing scope containing the PC (like addr2line
for example).

-Fred