This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC

On Nov 22, 2007 8:22 PM, Frank Ch. Eigler <> wrote:
> Mark Mitchell <> writes:
> > [...]
> >>      Who is "we"?  What better debugging are GCC users demanding?  What
> >> debugging difficulties are they experiencing?  Who is that set of users?
> >> 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.?
> >
> > That's what I'm asking.  First and foremost, I want to know what,
> > concretely, Alexandre is trying to achieve, beyond "better debugging
> > info for optimized code".  Until we understand that, I don't see how we
> > can sensibly debate any methods of implementation, possible costs, etc.
> It may be asking to belabour the obvious.  GCC users do not want to
> have to compile with "-O0 -g" just to debug during development (or
> during crash analysis *after deployment*!).  Developers would like to
> be able to place breakpoints anywhere by reference to the source code,
> and would like to access any variables logically present there.
> Developers will accept that optimized code will by its nature make
> some of these fuzzy, but incorrect data must be and incomplete data
> should be minimized.
> That they put up with the status quo at all is a historical artifact
> of being told so long not to expect any better.

As it is (without serious overhead) impossible to do both, you either have
to live with possibly incorrect but elaborate or incomplete but correct
debug information for optimized code.  Choose one ;)

What we (Matz and myself) are trying to do is provide elaborate debug
information with the chance of wrong (I'd call it superflous, or extra)
debug information.  Alexandre seems to aim at the world-domination
solution (with the serious overhead in terms of implementation and


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]