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

>>>>> "Roland" == Roland McGrath <> writes:

Tom> There's also an issue with knowing whether it is actually complete; I
Tom> didn't think of this until relatively recently:

Roland> I think we discussed this before and I've forgotten again why
Roland> that issue matters.  In the status quo there is a .debug_aranges
Roland> hunk for each CU from the beginning of the existing of the
Roland> corresponding .debug_info hunk at compile time, and that can
Roland> never be "stripped" except by strip et al that remove
Roland> .debug_info along with it.

Nothing requires a compiler to emit .debug_aranges for a CU.  It is an
optional index, at least by my reading:

    [6.1 Accelerated Access]
    ... a producer of DWARF information may provide...

So, if there is no aranges entry for a given CU, there is no way to tell
whether the CU has no addressable content, or whether the entry was
simply never created.

This is not an issue if you are willing to assume that the user is using
GCC, because AFAIK (modulo the bug we found) GCC always emits this with

GDB aspires to be more defensive, though.  So, on my current branch, if
GDB notices a missing aranges entry, it reads full symbols for the CU
just in case.  This triggers a number of times in OO.o.

The PR in question is suspended because I told rth that it wasn't clear
we would even be using aranges.

Overall this is fairly minor.  It isn't likely to affect Fedora.  I have
no idea what, if anything, other gdb maintainers might say about it.
Maybe we can just ignore it.

This issue affects .debug_pub* as well.


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