Re: Initial psymtab replacement results

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

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

Thanks for replying.

If we look at this as a gdb-specific format, then I suspect that is
actually a harder sell for Fedora.  It means more space and another
post-processing pass when making the debuginfo RPMs.

I'd hope this is surmountable, but it would be preferable to hide the
metadata processing somehow, because then we can involve fewer parties.
Having gcc generate it in a .debug section achieves this pretty nicely,
especially as gcc already generates these sections (more or less).

The other big drawback I see with the caching approach is that it means
that the first time will still be slow -- even with a system-wide cache
this will be true for the objfiles that a user changes during
development.


I understand the compiler problem.  If we had a program to rewrite the
appropriate DWARF sections, would that address the problems you have?
It seems to me that it would.


FWIW if we were going to do our own cache, I wouldn't put it in a form
like .debug_gnu_index or .debug_pub*.  I'd just have gdb write out a
mappable data structure.

One definite positive about the branch is that these changes are a lot
simpler now.  The psymtab stuff is mostly isolated, and writing a new
"back end" is reasonably self-contained.

Tom