This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] Basic support for producing DWARFv5 .debug_addr section
ClosedPublic

Authored by vleschuk on Jul 30 2018, 12:48 PM.

Details

Summary

This revision implements support for generating DWARFv5 .debug_addr section. It is dependent on https://reviews.llvm.org/D49676 as we need working consumer to execute test.

The implementation is pretty straight-forward: we just check the dwarf version and emit section header if needed.

Diff Detail

Repository
rL LLVM

Event Timeline

vleschuk created this revision.Jul 30 2018, 12:48 PM
vleschuk updated this revision to Diff 158054.Jul 30 2018, 12:59 PM

This revision implements support for generating DWARFv5 .debug_addr section. It is dependent on https://reviews.llvm.org/D49676 as we need working consumer to execute test.

The implementation is pretty straight-forward: we just check the dwarf version and emit section header if needed.

UPD Changed type for AddrSize from uint32_t to uint8_t.

dblaikie added inline comments.Jul 30 2018, 6:47 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
2299–2307 ↗(On Diff #158054)

I'd sink this functionality down into AddressPool::emit instead - it can query the AsmPrinter for DWARF version & decide what format to produce the address pool in internally.

test/DebugInfo/X86/debug_addr.ll
9 ↗(On Diff #158054)

These return statements seem unnecessary? (in the text of this comment, and in the IR of the sample - not that it'd make much of a difference)

24 ↗(On Diff #158054)

There's no header in debug_addr sections in DWARFv4, is there - what's this then?

Also is this consistent with the way other section contributions are described (I don't recall text like "Addr Section params" in other output - like the way those attributes are printed out like "Compile Unit: ..." rather than "Unit Section params")?

vleschuk marked 3 inline comments as done.Jul 30 2018, 11:11 PM
vleschuk added inline comments.
test/DebugInfo/X86/debug_addr.ll
9 ↗(On Diff #158054)

Removed them from the comment, not sure that I understood what do you suggest to remove from IR (IR code would be the same with or without explicit return statements in C code).

24 ↗(On Diff #158054)

Changed it in dependency revision: https://reviews.llvm.org/D49676.

vleschuk updated this revision to Diff 158173.Jul 30 2018, 11:14 PM
vleschuk marked 2 inline comments as done.
  • Adopted producer test to match recent changes (got rid of "params" from "Addr Section params" message).
  • Removed explicit return from test sample
  • Moved header emission to AddressPool class
vleschuk added inline comments.Jul 30 2018, 11:17 PM
test/DebugInfo/X86/debug_addr.ll
24 ↗(On Diff #158054)

There's no header in debug_addr sections in DWARFv4, is there - what's this then?

You are correct, there is no header, these values are taken from CU. In code they still are placed into Header structure and I think it is useful to dump this structure into output.

dblaikie accepted this revision.Jul 31 2018, 3:00 PM
dblaikie added inline comments.
test/DebugInfo/X86/debug_addr.ll
9 ↗(On Diff #158054)

I meant update the IR to match the changed text - but really all it's going to do is change the DebugLoc of the ret IR instruction, which isn't a big deal. No worries.

24 ↗(On Diff #158054)

As for the name/header - maybe take a look at all the other sections to see about something consistent. For example it looks like other header printing (debug_info/types, pubnames/types, etc) doesn't use a comma between values. But otherwise looks like what you're showing is modeled fairly closely off the printing of compile units? Seems OK if you could unify them a bit more (skip the commas, for example).

I'd still skip the header parameters in the case where they are not present in the binary format - to make the dump more accurately communicate what data is being rendered/where it's coming from.

& I'd probably skip the "Addr: [" wrapper - most of the other dumping dumps the contents without a container/braces/etc, I think? (sometimes with a header for columns if there are multiple columns)

This revision is now accepted and ready to land.Jul 31 2018, 3:00 PM
This revision was automatically updated to reflect the committed changes.