>>>>> "Roland" == Roland McGrath
<roland(a)redhat.com> writes:
Roland> The only rationale I've heard for empty ranges is Tom's idea
Roland> that every CU should be the rhs of some .debug_aranges entry
Roland> just so you can be sure that .debug_aranges is really complete
Roland> (vs. a buggy old GCC, or some different letter-of-DWARF producer
Roland> where some CUs with actual PCs had no .debug_aranges data
Roland> emitted, is what I assume Tom must have in mind).
I see it as following the wording of the standard. .debug_aranges is
optional. Therefore it may or may not exist for a given CU.
That's exactly what I meant by "letter-of-DWARF" above. But, DWARF just
talks about "producers" in a unitary, or rather, vague, way. It's not at
all clear about compilers vs linkers and so forth. For the quick-lookup
sections to be much use at all--especially a by-address one--you pretty
much need to have all the CUs that get linked together to have been
compiled consistently.
I think this, like several other things in DWARF, is pointless and
bad
-- but it is what we've got.
I don't know if there is any plausible scenario where this could really
happen. Maybe hand-written assembly?
Do you mean hand-assembled DWARF, or gas -g? Hmm. My only guess was
either buggy compilers, or some non-GCC compiler that built some library
then linked together with GCC code or something.
But I don't actually know off hand about gas -g (or gas assembling explicit
.loc directives), I'd forgotten that's another producer we have.
Assembling the trivial file "foo: nop" with -g on f13/x86-64, I do see
it generates a .debug_aranges. Assembling a trivial data-only .s file
(e.g. just ".comm x,4") with -g, it emits no DWARF sections at all.
It would be very interesting to see a .debug_aranges report from
dwarflint run on everything in F13 or F14.
I think Petr may be set up to do that easily. (If you weren't already
aware, you can look at debuginfo-test-scripts, it's in the Google hits
for that token. It might have bit-rotted.)
I ran across this while trying to code defensively against the
standard.
Perhaps this is me being too pedantic. OTOH, the lax route has not
worked out very well for gdb historically -- DWARF changes causing
crashes, etc.
Right now, GDB isn't using aranges at all. I guess it could; we could
drop the range info from the index.
FWIW, libdw has always depended on .debug_aranges and its by-address
lookups will fail completely to notice any CUs not represented there.
We haven't seen any problems in the wild. But, stap does little if
anything that really relies on by-address lookups, and nothing based
on libdw has probably ever been used anywhere near as much as GDB in
the kinds of ways where those are important.
If we do that, I will make it follow whatever you decide here. I
don't
actually care all that much. Actually, I tend to think we should fork
DWARF a little to fix its most egregious problems.
I'm not sure I'd call this a fork, but maybe I don't know exactly what you
mean. DWARF is such a vague standard for the corners anyway. IMHO for all
the optimized lookup sort of stuff what's going to be useful is fresh new
extensions/sections rather than tweaking the stuff already specified. For
all those things, anything you'd really choose as optimal is stuff you need
to do at link time or after, rather than stuff the compiler/assembler can
emit in fragments to have generic linker features stitch together. Good
choices for consumers to use efficiently don't mesh with things you can
emit with standard relocations to come out correctly, you'd like tables
sorted on final-linked address for direct binary search of the data mapped
untouched from the files, etc.
This (as a vague set of ideas) is one of the subjects on which I mean to
write up notes for discussion in person on the GCC Summit trip and still
haven't yet. (I don't have any even slightly-specific ideas about any
name-based lookup stuff, just by-address stuff.)
Thanks,
Roland