This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Initial psymtab replacement results

On Fri, Dec 11, 2009 at 04:09:49PM -0700, Tom Tromey wrote:
> I'm leaning toward ditching the .debug_gnu_index idea and simply going
> with the standard sections instead.  Let me know what you think of this.
> As far as I know the .debug_pub* approach is ok assuming (1) we take
> Cary's suggestion of changing gcc to put everything in it, and (2) parse
> the producer to see when the sections are usable.

I want to get my comments on this into email, since IRC isn't a
productive tool for this sort of discussion.  This is pretty much
the same as what I said on IRC yesterday.

I still strongly support the idea of a debugger-specific cache,
for the reasons below.  There's prior art (according to Paul P.); we
know this approach is practical.

* It is simple to version and extend.  If the cache is too old, either
use what is there or ignore the cache.  I believe that DWARF producer
checks, while pragmatically necessary to work around some bugs, should
be avoided whenever possible.  And who knows what compiler versions
end up with this backported to them.

* It is still simple to preseed at distribution time.  For instance,
merge the cache generation process with whatever you use to generate
separate debug info files, and put a cache there - with associated
version, so that GDB knows what is and isn't in that cache.  No need
to maintain a local cache in $HOME if there's already one in

* You've already had to make changes to GCC for this project.  If you
have to change GCC again, there's more users out there with even more
backported and hacked up compilers that you have no idea whether
pubtypes is complete enough.

* Rolling out new compilers to people who want a new debugger may be
easy for Fedora, but it just aint so in the rest of the world.  We
routinely get requests from customers who want to upgrade their
debugger and continue to use the compiler they've validated for the
past year.  Changing the debugger is cheaper than changing the
compiler, even if the work is already "out there" in trunk.

* We also have customers using non-GCC compilers.  You have users
doing this too: icc, for instance.

Daniel Jacobowitz

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