This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Eliminate duplicate dwarf2 data
- To: Jason Merrill <jason at redhat dot com>
- Subject: Re: [PATCH] Eliminate duplicate dwarf2 data
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Sun, 27 Aug 2000 09:32:15 -0700 (PDT)
- cc: gcc-patches at gcc dot gnu dot org
On 27 Aug 2000, Jason Merrill wrote:
> >>>>> Daniel Berlin <dberlin@redhat.com> writes:
>
> > This patch, and the associated linker patch, combined, will eliminate
> > duplicate dwarf2 debugging info.
>
> Thanks for moving forward on this, since I wasn't.
It gave me a chance to get into some of gcc's internals for debug output
generation, so it was fun.
>
> > I tried doing it in the linker, but it requires duplicating all of
> > dwarf2read.c from gdb, and all of dwarf2out.c from gcc, and still doesn't
> > do as good a job.
>
> Why, given the compiler changes to generate multiple compilation units,
> can't the linker just go through and discard CUs with the same checksum
> rather than use linkonce sections?
Not without a *lot* of code to handle it.
It's not as simple as marking those we want to remove, and then not
writing them.
Or at least, not yet.
I think the problem was twofold.
1. As an optimization to avoid generating too many *used* labels, I have the
compiler determining if two DIEs (IE the DIE for the current thing, and
whatever DIE that we want to point to in some attribute) have the same
parent, and if so, outputting it as an absolute offset, rather than a
relative. So if you go do this in the linker, you have to recalculate all
the die offsets, and rewrite them.
2. Something i can't quite remember at the moment, but it made me give up
trying to do it in the linker entirely. I really wish i could remember
what it was. I want to say we were getting ahold of it at the wrong time,
like after the labels were gone and it had relocated everything, so that
we'd need to rewrite all the info. But i don't remember if that was
really the issue or not.
Damnit. I'll rerespond when i remember.
Then lastly, we had
3. It didn't seem to make sense to have the linker duplicate the code the
compiler and debug reader were doing, when each of those required the code.
>
That would mean that an upgraded linker
> would just produce smaller results, rather than being required for
> correctness.
>
With -fno-eliminate-dwarf2-dups, an upgraded linker is not required for
correctness.
> Would you mind if I took over the compiler side work? You've gotten me
> interested again. :)
Go for it.
My approach is slightly different than yours (mainly in that i don't
leave the EINCL/BINCL tags in the output, I build one abbrev table for
all the compilation units we are outputting, rather than multiple ones,
and my pubname are correct. Also, due to annoying things going on in
the compiler, where your tests to determine if we should comdat
something stopped working, i comdat each include file, rather than
figure out what dies we should be comdating.), if you look at verbose
assembly output, it should be easy to tell what i'm doing different.
--Dan
>
> Jason
>