Page MenuHomePhabricator

DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers

Authored by dblaikie on Nov 7 2018, 5:06 PM.



Ranges base address specifiers can save a lot of object size in
relocation records especially in optimized builds.

For an optimized self-host build of Clang with split DWARF and debug
info compression in object files, but uncompressed debug info in the
executable, this change produces about 18% smaller object files and 6%
larger executable.

While it would've been nice to turn this on by default, gold's 32 bit
gdb-index support crashes on this input & I don't think there's any
perfect heuristic to implement solely in LLVM that would suffice - so
we'll need a flag one way or another (also possible people might want to
aggressively optimized for executable size that contains debug info
(even with compression this would still come at some cost to executable
size)) - so let's plumb it through.

I'm open to suggestions on naming - I suppose having "debug" in the name of the metadata attribute is a bit redundant - of course it's debug related when it's there. How fully qualified should the name be? "useRangesBaseAddressSpecifiers" is a bit of a mouthful. "rangesBaseAddresses: true" ? or just "baseAddress: true" baseAddresses?

Diff Detail


Event Timeline

dblaikie created this revision.Nov 7 2018, 5:06 PM
aprantl added inline comments.Nov 7 2018, 5:15 PM
1399 ↗(On Diff #173093)

I guess we don't need an extra upgrade test because there are already plenty older format CUs in .bc files that also exercise this?

120 ↗(On Diff #173093)

Are those necessary?

dblaikie updated this revision to Diff 173100.Nov 7 2018, 5:24 PM

Remove unnecessary attributes and add test input description

dblaikie added inline comments.Nov 7 2018, 5:25 PM
1399 ↗(On Diff #173093)

Yeah, that was my thinking!

120 ↗(On Diff #173093)

Oh, nah - removed them and updated the test to have some comments about the original source & what it's testing with the different pieces.

Is this going to be used for anything other than ranges? If not I'd slightly prefer rangesBaseAddress over debugBaseAddress.

Is this going to be used for anything other than ranges? If not I'd slightly prefer rangesBaseAddress over debugBaseAddress.

Yeah, seems reasonable. (I'll hold off on actually making the naming change until I get a sense everyone's roughly on the same page)

It's /possible/ we would want to configure the use of certain forms (including base address specifiers) in debug_loclists.dwo in v4 mode (this change already only applies to v4 - in v5 we use rnglists & expect a conformant implementation that handles all the v5 loclist entry kinds) - seems GDB only supports the forms we already use in v4, even though there are more efficient forms we could use (& it only supports the efficient forms in v5 standard loclists - not the forms we use in v4... ). But probably best to just move to v5 there, rather than trying to get v4 support in GDB to handle it, then have a conditional flag for users who have the fixed GDB or don't, etc. See this commit for some details about that fiasco:

echristo accepted this revision.Nov 8 2018, 4:45 PM

Naming sounds ok to me :)

This revision is now accepted and ready to land.Nov 8 2018, 4:45 PM
This revision was automatically updated to reflect the committed changes.

Settled on renaming the DICompileUnit attribute from debugBaseAddress to rangesBaseAddress (since 'debug' is redundant, and this is really specific to ranges base address specifiers).