[Dwarf-discuss] DW_AT_ranges info generated by gcc

[Chris Quenelle]

This is a bit of a ramble, beware .... ;-)

It seems that dwarf consumers can be trained to cope with
either behavior, but it seems like it should be documented
in the standard so consumers know what to expect.

I consider this to part of the a very difficult general
problem.  When optimizations are present, the structure
of the machine code no longer corresponds directly to the structure
of the source code.  Should the structured elements of dwarf
match the structure of the source code or the structure
of the machine code?

In the machine code, the two functions in your example
are merged, and represent one machine-level ABI "function".
Even though they represent two distinct source-level "functions".

The answer to this question for inlines might be different than the
way we want to deal with "nested functions" that are truly
nested in the source code, or nested block scopes in a C or C++
program.

We could also make a simplifying decision:

When a segment of machine code represents an underlying ABI
function, then the range of address for that function
should span the entire function.  Inlined function bodies,
and nested scopes may also be described with address ranges
spanning various subsets of these instructions.

--chris



Fred Fish wrote:
> 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
> 
> 
> 
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/dwarf-discuss