Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov  7, 2007, David Edelsohn <dje@watson.ibm.com> wrote:

> 	Who is "we"?  What better debugging are GCC users demanding?  What
> debugging difficulties are they experiencing?

I, for one, miss the arguments of inlined functions, a lot.

The reason for that is that arguments are currently optimized away to
boot.  Even if they weren't, since they're initialized with a trivial
copy, at least their initial value (quite often preserved throughout
compilation) would be gone to boot.

On top of that, we currently regard arguments and variables of
non-inlined functions as special, and we prevent a number of
optimizations with them, in order to be able to generate slightly
better debug information for them.  (As for arguments and variables of
inlined functions, we happily drop them on the floor right away.)
This is not only inconsistent, it's also harmful, because we're
trading performance and compile-time memory for slightly better but
still incorrect, incomplete and unreliable debug information.


> Who is that set of users?

I'm personally getting numerous requests for debug information
correctness and better completeness from debug info consumers such as
gdb, frysk and systemtap.  GCC's eagerness to inline functions, even
ones never declared as inline, and its eagerness to corrupt the
meta-information associated with them, causes these tools to
malfunction in very many situations.  And it's all GCC's fault, for
generating code that is not standards-compliant in the
meta-information sections of its output.

> What functional changes would improve those cases?  What is the cost of
> those improvements in complexity, maintainability, compile time, object
> file size, GDB start-up time, etc.?

Before I spend hours describing the little I can foresee about this,
how much of this really matters, given that it's mostly a matter of
correctness, rather than mere trade offs?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}