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

> 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'm quite sure we can roll it into the one post-processing pass when we do
the expected change to make that rewrite the DWARF data more than it does
already anyway.  In fact, for Fedora it's probably easier to do this than
anything else (i.e. nobody else but me will ever try to understand it
anyway!).  But, really, in the Fedora-centric context we have numerous
options and really not all that many constraints on approaches.  So this is
mostly neither here nor there as to the general subject of wise GDB features.

> 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).

OTOH this approach inherently involves some suboptimally and probably at
least a little duplication.  (Also, try to consider COMDAT and be afraid.)
A post-link procedure gets the benefit of knowing how all the little CUs
got linked together, as well as not having to try to produce a
linkable/relocatable result.

> 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.

Either the compilation is slower or the first debugging is slower.  In
theory it's about a wash, but of course that theory does not account for
the residency of all the relevant bits at compilation time nor for any
inherent benefit the compiler gets as emitter using its own internal
representations vs something that reads the compiler's vanilla DWARF to
build its index.

> 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.

IMHO the big benefit of it being done on-demand by GDB itself (or perhaps
equivalently by an entirely separate post-processing phase not rolled into
other build-time DWARF fiddling) is that GDB has a free hand and no real
version skew issues in evolving this format.  Even if it's purely a
post-processing step rather than a compiler feature, if that is done as
part of package building, the index format immediately becomes a fairly
real and stable binary file format with all the attendant compatibility
issues and constraints on the ongoing development.

> 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.

Well done!


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