This is the mail archive of the gcc@gcc.gnu.org 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: When to emit C++ debug info?


On Sun, Jan 04, 2004 at 12:09:11PM -0800, Geoff Keating wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Sun, Jan 04, 2004 at 03:12:11AM -0800, Geoff Keating wrote:
> > > > Date: Sun, 4 Jan 2004 02:36:06 -0600 (CST)
> > > > From: Chris Lattner <sabre@nondot.org>
> > > 
> > > > On Sun, 4 Jan 2004, Geoff Keating wrote:
> > > > > > This is precisely the kind of thing that caused the original problem: lack
> > > > > > of debug information being emitted when you just _use_ libraries.  ie, you
> > > > > > don't recompile them, so you only have debug information for part of the
> > > > > > program.
> > > > >
> > > > > The design you quoted at the top was directed at the first alternative.
> > > > 
> > > > Ah, I see: Sorry!  But isn't this basically what already exists?
> > > 
> > > I think so; but this thread is proposing to change what's there now,
> > > isn't it?
> > 
> > I think that my point is, in the absence of something like symbol
> > separation implemented for dwarf2, the current status quo is not
> > adequate.
> 
> No, *my* point is that you don't need symbol separation if you have
> something like the design I proposed.
> 
> I really think that symbol separation is not the best answer.  We've
> tried it at Apple, and although it's quite clear that it works, it's
> also clear that it's difficult to use.  A solution that works nearly
> as well, but doesn't require any effort to use, will be much better,
> because then people will actually use it.
> 
> > It sounds like Ben agrees with me and you don't - you said a dozen
> > messages back that you thought distributors should provide debug
> > information for libraries.  I can tell you for a fact that that will
> > never happen.  A lot of vendors provide binary-only C++ libraries with
> > a C++ interface.  People in the business of providing code without its
> > source generally don't want to include debugging information, so GCC
> > needs to be able to provide useful results for this case.
> 
> You can always generate debugging information from the headers, if
> you're a user who has been given a library without debugging
> information---or just ask for full debugging information from the
> compiler for one file in your project that uses the library.  I think
> that full information shouldn't be the default, though, because the
> circumstance of using a binary-only C++ library which has no debugging
> information is fairly rare and the problems caused are minor and
> easily fixed if encountered.
> 
> By 'distributors', I meant system distributors, who provide an OS and
> a compiler; like Red Hat, Debian, Apple, MontaVista.

OK, in that case I have to disagree with your "I can't see why anyone
would want something between these two extremes".

First of all you what you are calling full debugging information is
vastly larger than anything we emit today, or have emitted in the past
- that is, debugging information for every type or function declared in
a header, et cetera, not just referenced ones.  What I suggested is
between those extremes and considerably smaller for typical C++
headers.  Secondly this means you'd have to do that for a file which
included every header provided by a library without debug information,
so it still would require some build system changes - probably not too
complex, but not necessarily.

I disagree that the circumstance is rare - maybe in the Open Source
world it's rare, but for people developing on proprietary systems it's
pretty standard.

And the concept of shipping debugging information for every C++ library
in Debian in order to be able to debug programs which use those
libraries is a truly gruesome one.  Almost no one wants the debug
information for all of QT, and GDB doesn't want to load it
unnecessarily either.  And our mirrors certainly don't want to, since I
estimate it would be a minimum of 70MB just for one copy of QT 3.x. 
Add in that people develop using the shipped shared library components
of Mozilla, well, you see where I'm going.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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