This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: When to emit C++ debug info?
On Jan 4, 2004, at 12:09 PM, 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.
We (Apple) want to implement symbol separation or some other better
solution for DWARF also.
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.
Allow me to briefly explain symbol separation here to make things clear.
Step 1)
User collects separate debug info for large header in special .o files
(aka symbol repository). These .o files contains only debug info and
this step requires separate invocation of compiler (just like building
PCH) and most of the times it needs to do it once only. For example,
QT user needs to do this only once for QT headers.
Step 2)
While compiling source files, when compiler process include directives,
it looks for symbol repository in include paths. If one valid repository
is found for the given header, compiler turns off debug info generation
for types in the header.
Step 3)
During linking step, user needs to supply special .o files to linker
so that linker can add them in final binary.
For a large complex project, adding step 1) and step 3) in build system
may turn out to be not very trivial.
Now, Step 3) can be eliminated if debugger can separately load debug
info
from symbol repository directly. This can allows library supplier to
supply
debug info for the exported types with the library.
Step 1) can be eliminated if compiler can generate symbol repository on
the fly for large headers. If symbol repository are stored on a
physical file on disk then some sort of sync. is required. Plus compiler
needs some hints about large header. Generating symbol repository for
each header is not a good idea. I think, Compiler Server can help here.
--
Devang