This is the mail archive of the gcc-patches@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]

Re: [PATCH] Eliminate duplicate dwarf2 data





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
> 

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