> >>>>> "Roland" == Roland McGrath <[email protected]> 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
