[Dwarf-discuss] dwarf information for mutiple statements at thesame line.

[Todd Allen]

On Mon, Jul 17, 2006 at 01:19:04PM -0700, Chris Quenelle wrote:
> 
> I think the HP scheme described by Cary seems to be a good
> design in terms of density.  But the simple name of a routine has
> proven to be only a fuzzy way to identify a function
> when combined with C++ and templates and overloading. I
> try to stay away from forcing the debugger to resolve
> names to program objects, in favor of using addresses
> and direct pointers where possible.
> 
> It seems like it would be better to have the line number
> table reference an offset within the debug_info section
> as a way to identify which function got inlined.  And
> if we're going to do that, why not point to the
> DW_TAG_inlined_subroutine die instead of the DW_TAG_subroutine die?
> 

This would be the first time the .debug_line information made reference to
the .debug_info section.  (See Appendix B.)  And, as a result, it would
damage one of the stated advantages of the .debug_line-based scheme as it was
described: that the information could be provided even if full debug support
(i.e. .debug_info) wasn't provided.  Similarly, it would be problematic for
some strip tools that are able to remove all the debug information except the
.debug_line, precisely because part of the .debug_line information couldn't
be interpreted without the .debug_info any more.

The DW_TAG_inlined_subroutine is more robust the the .debug_line-based
information because it allows you to determine the logical nesting of inlines
and all related entities, such as formal parameters, local variables, etc.
It allows a consumer to present pseudo-frames to distinguish between the
inline "callers" and inline "callees" and to distinguish entities in scope in
either.  And because that DW_TAG_inline_subroutine mechanism already existed,
that's why DW_AT_call_* was added there.  The DW_AT_call_* attributes are
pretty efficient if you already were generating DW_TAG_inlined_subroutine
DIE's in the first place.  But, of course, as has been pointed out, they are
of no value if you don't generate .debug_info.

The ability to specify multiple (file,line,column) coordinates with a
specified nesting for a single PC probably would render the DW_AT_call_*
attributes unnecessary, I think.  But for purposes of determining what
objects are visible, if we want to maintain the current relationship where
.debug_line never refers to .debug_info, then the DW_AT_low_pc/DW_AT_high_pc
or (more likely) DW_AT_ranges still would be necessary to determine the
correct DW_TAG_inlined_subroutine DIE's in the .debug_info.

-- 
Todd Allen
Concurrent Computer Corporation