This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Do not dump header field for pre-DWARF5 address tables.
ClosedPublic

Authored by ikudrin on Feb 6 2020, 10:38 PM.

Details

Summary

As there is no header in pre-DWARF5 address tables, and we fill the class data members with some artificial values, we should not dump them as that might be misleading.

Diff Detail

Event Timeline

ikudrin created this revision.Feb 6 2020, 10:38 PM
jhenderson accepted this revision.Feb 7 2020, 1:03 AM

I'm okay with this, but might be worth waiting for the opinion of others.

This revision is now accepted and ready to land.Feb 7 2020, 1:03 AM

What do GNU tools report for a v4 .debug_addr section? Intuitively I'd want to see something that says what's going on, rather than have it look like we just forgot to print the header.

What do GNU tools report for a v4 .debug_addr section? Intuitively I'd want to see something that says what's going on, rather than have it look like we just forgot to print the header.

There's not much else to print, really - much like other pre-v4 sections with no separators (eg: debug_ranges) it's a flat list of things, from all the different contributions.

I'm pretty sure pre-v5 we didn't even print the "Addrs: [ ... ]" wrapper, it was ".debug_addr contents: " then lines of "<offset> <address>" pairs & that was it, maybe?

But yeah, fair question as to what binutils/GNU tools do in case there's some inspiration.

The output of readelf looks like this:

Contents of the .debug_addr section:

  For compilation unit at offset 0x0:
	Index	Address
	0:	00000000 
	1:	00000010 
	2:	00000018

As far as I remember the internals of GNU utilities, they parse .debug_info first and use references from there to parse other sections.

@probinson, @dblaikie, are you OK with this patch, or you still have any concerns?

dblaikie accepted this revision.Feb 11 2020, 9:49 AM

Fine by me - thanks!

So the nonstandard .debug_addr section is identified by having a reference from a v4 .debug_info section... I guess there's no better way.
Yes, LGTM

This revision was automatically updated to reflect the committed changes.