RE: Contribution to egcs

["Daniel Berlin" <dberlin@msn.com>]

>
> One thing that might help me to get started is finding docs on the DWARF2
> spec / implemetation notes.

Um, where did i see them last.
Damnit.
It's dwarf-2.0.0.*, just ftpsearch it.
If you can't find it, i'll try to hunt it down.
>
> I would like to find a way the the redundant info was not written to the
> .o files in the first place... perhaps an option for all the DWARF2 info
> to be written to a projectname.dwf file, limit the redundncy in some
> effecient way and modify the debugger to look for the dwarf info in that
> project.dwf file rather than in the executable.  It might wind up being
> DWARF3 or some such thing. It sounds like a lot of work.

Well, perhaps a little more detailed explanation of the problem would help.
The problem actually occurs on all systems using DWARF2 info, AFAIK.
It just is noticeable on BeOS because of the number of C++ headers the
average file includes.
What is happening is that the debug info for the "system" headers keeps
getting output for every single file that you compile (or at least, a *lot*
of the system headers). This generates a ton of debug info.  99% of it, is,
of course, redundant.
This is also the reason the "fatfile" trick (including source in one big
file) works. It only sees the headers once, and only writes debug info once.
Now, the immediate solution that comes to mind is to add a complete hack so
that gcc knows that it already output debug info for the system headers,
between compiles.
Smart thinking, right?
Wrong.
You can't, because of the way DWARF2 works.
See, the type info and whatnot in DWARF2 ends up being references to
previous DWARF2 records (or future ones, or am i wrong about this. I'm
trying to remember this, i apologize).  Except for the first time it's
output, of course.
You'd have to add the ability for gcc to remember "DWARF2 state" between
compiles, and then modify the linker to know this is what your doing (IE
that it should merge the .o file with the system header debug info first) or
else it wouldn't know where in the DWARF2 info "int" was (among other types
and such), and things would really get screwed up.
DWARF2 is pretty convoluted in this respect. It seems nobody ever stopped to
think about the problem when writing the spec.  Like if someone actually
started *using* it for large C++ projects, well, we'd just figure out what
to do then.  Welcome to then.
Another solution i can think of off the top of my head is to somehow output
something (DWARF2 has room for extensions) that tells it "oh, this type is
in a system header, we'll let LD figure out the real reference number", and
then modify ld to do just that.
I had some better ideas when i spent about 2 weeks doing nothing but trying
to figure out how to solve this problem, but i determined rather quickly
that any solution would take me months to implement, and i don't have the
free time. :(



>
> I may be getting ahead of myself before I have seen the source and
> implementation notes for the c++ compiler / DWARF2 etc.
>
> Pointers are appreciated.

Dwarf2out.c is your friend and enemy.
>
>
> cheers,
> --BQ
> --------------------
> Bruce Q. Hammond
> Gobe Software, Inc.
>
>
>
>
>
>
>
>