Re: Removing duplicate DWARF2 info

[Mike Stump <mrs at windriver dot com>]

> Date: Mon, 10 Jul 2000 23:54:33 -0400 (EDT)
> From: Daniel Berlin <dberlin@redhat.com>

> I know this has been hashed over before, but nobody ever seems to do
> it where it needs to be done (I do it in GDB when we load the
> stuff), and i'm guessing it's because there are three people on the
> planet with the knowledge of how LD works that can make this happen.

If you did it the right way, in bfd, and if bfd handled all things
symbol, then enabling ld to make use of it also should be easy for
you...  But alas, I fear it wasn't quite done like this.

> Why can't we simply not emit the duplicate info, taking LD out of
> the picture completely.  All it seems this would entail is keeping
> track of what we've emitted info for, over the course of more than
> one file.  Couldn't we have a simple persistent hash table in a
> file, and do a lookup in that, then do the check to see if we
> emitted it during this compilation?  That doesn't really seem that
> tricky to do, or am i missing something?

I often argue for a generic along side database.  The repo database
almost fits that role.  With such a beast, quite a few things become
trivial.  I don't happen to think you're missing too much, assuming
you already know about things like usage of .o files in more than one
executable/library.

Profile base feedback for branch prediction I would argue wants it,
improving compilation speeds for C++ wants it (think in part
precompiled headers), debugging dups want it, templates want it...

> From: Zack Weinberg <zack@wolery.cumb.org>
> Date: Mon, 10 Jul 2000 21:06:20 -0700
> To: Daniel Berlin <dberlin@redhat.com>

> Do you want to teach every makefile in existence about this persistent
> hash table?

Since the repo database could in fact be used to do exactly what is
requested, and since I have in fact not seen a lot of repo stuff in
Makefiles, I'd think this is a slight overstatement of the reality of
the situation, though, without 5 years of experience on a new system,
I do agree, peering into the future is at times, hard.