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

[Jim Blandy]

On 7/11/06, Ron Brender <ron.brender at charter.net> wrote:
> I believe Michael is correct. Basically, just treat every token in the
> macro expansion as though it occurred at the location of the macro
> invocation

This is the way the GNU toolchain handles it, but I'm not sure I see
why it's necessary, or even preferable.  If one can accurately
attribute particular instructions to a macro definition, why shouldn't
one?  Especially when dealing with multi-source-line macros, it would
be really nice to be able to step through them.

I understand that, as granularity becomes finer, it's harder to
attribute individual instructions accurately.  That's true, but I've
dealt recently with code with macros tens of lines long; this
objection doesn't apply there.

I understand that the preprocessor splices multi-line macro
definitions together into a single logical line.  But this is an
internal translation process; there's no reason a toolchain must throw
away information about the positions code had in the source code as
written.

I understand that some debuggers don't do a good job handling the case
where a single source line is attributed to many instructions
scattered throughout the program.  But this seems like an issue with
the quality of the user interface, not a problem for the producer to
fix by emitting less accurate debugging information.

In other words, the source for Keith's call to f1 is on the line
defining the macro --- why shouldn't the debug info say so?  Why is
the post-processed program the "real" program, and the code as it
exists in the user's file not?  It seems more useful to put it the
other way around.