[Dwarf-Discuss] Lexical block address ranges when nesting

[Martin Day]

Thanks for all the replies on this issue. I agree with Ron's email too. I think it would probably be helpful to explicitly state this in the standard. 

Gcc seems to include the address ranges of child lexical blocks in the parent and it seems to make sense to do it this way as the variables declared in the parent block will be in scope whilst executing instructions in the child lexical block (for C/C++ code anyway).

One slight variation on this is would you expect a parent lexical block to include the address ranges of the code of an inlined subroutine block? If a debugger user single stepped onto an instruction from the inlined subroutine then the debugger may well show them located on the source code of the subroutine and it may confuse them to show them variables from the enclosing blocks which aren't actually in scope. I guess the question is : can the debugger just rely on the address ranges to determine which variables are in scope or should it just use the scope block types (subroutine, lexical block, inlined subroutine, etc.) or must it use both? 

Are the addresses there simply for the debugger to search the scope tree to find the most deeply nested block in scope and then work back up the tree from there or do they actually specify at which addresses the variables declared in the block are in scope by the rules of the language being compiled?

Should it be guaranteed that the address ranges of child nodes are contained in the address ranges of their parent nodes and that the address ranges of sibling nodes do not overlap?

Most of our users need to be able to debug optimised code so anything we can do to improve that by generating better debug information would be welcomed by them.

Martin



-----Original Message-----
From: Michael Eager [mailto:eager@eagercon.com] 
Sent: 08 November 2008 19:36
To: Ron Brender
Cc: Martin Day; dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] Lexical block address ranges when nesting

Ron echoes my thoughts on this.

A lexical block contains all of its nested inner blocks.  In DWARF,
each block would have a low_PC and high_PC value, unless the block
really is discontiguous.


Ron Brender wrote:
> The computer science concept of a lexical block is inherently inclusive 
> of any blocks nested within (so-called inner blocks). As a consequence, 
> it never occurred to this complier implementor and the debugger 
> implementors he has worked with over the years to exclude the inner 
> blocks when generating the debug info for a block.
> 
> In a non-optimized compilation, it will normally be the case the every 
> lexical block (including every function body) can be described by as a 
> single contiguous range of instructions (using DW_AT_low_PC and 
> _high_PC) if blocks are considered inclusive of inner blocks. If inner 
> blocks are excluded, then any block containing a inner block becomes 
> discontiguous (usually) and would require the more complicated 
> DW_AT_range attribute to describe.
> 
> I don't recall anywhere else in the document where the concept of block 
> is explicitly defined. But I also find it hard to read Section 3.4 in a 
> way that allows either inclusive or exclusive interpretations.
> 
> I see no advantage for DWARF as a specification to be ambivalent about 
> whether blocks are inclusive or exclusive. But if that were the intent, 
> the I would argue that DWARF really needs another attribute that 
> specifies which interpretation is being used by a particular version of 
> a particular producer on a particular architecture (this week). 
> Otherwise, debugger implementations become less portable and must build 
> in additional knowledge about "known producers". (Yes, there is some of 
> this already but I see no value in it in this connection.)
> 
> Ron
> 
> -----------------
> Martin Day wrote:
>> Section 3.4 of the dwarf3 spec says :
>>
>> "The lexical block entry may have either a DW_AT_low_pc and DW_AT_high_pc
>> pair of attributes or a DW_AT_ranges attribute whose values encode the
>> contiguous or non-contiguous address ranges, respectively, of the machine
>> instructions generated for the lexical block (see Section 2.17)."
>>
>> We're compiling C/C++ using DW_AT_ranges. Should the ranges specified 
>> for a
>> lexical block include the ranges of all nested (child) lexical blocks or
>> should it only be the address ranges of instructions generated for that
>> lexical block as the quote above seems to imply or is it undefined and
>> implementation dependant?
>>
>> Compiler writers say it's easier for them to just list the ranges for
>> instructions in the block excluding those in nested blocks. Debugger 
>> writers
>> would prefer the ranges of a parent block to include all the ranges of 
>> child
>> blocks so that a tree search is easier.
>>
>> Is this explicitly defined somewhere in the standard or should the 
>> debugger
>> be able to cope with either method?
>>
>> Thanks
>>
>> Martin
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> 


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077