[llvm-dev] DWARF: Ranges base address specifier entries & Gold's gdb-index 32 bit bug

[Nico Weber via llvm-dev]

On Aug 7, 2017 6:58 PM, "David Blaikie" <dblaikie at gmail.com> wrote:

Context:

In r309526 (with a followup fix in r309529) I implemented the use of
DWARF's debug_ranges base address specifier entries to reduce the number of
object file relocations needed for debug_ranges*.

* in a particular binary internally, an optimized build had a 70% reduction
in debug_ranges.reloc, a 16% decrease in total object size (with compressed
debug info and fission)

Nico noted that this broke the Chromium build ( https://bugs.llvm.org/show_
bug.cgi?id=34007 ). Turns out GNU Binutils Gold has a bug (I've reported it
as: https://sourceware.org/bugzilla/show_bug.cgi?id=21894 - wouldn't expect
much action on it, though) where it fails to parse a base address specifier
entry when trying to build gdb-index (-Wl,-gdb-index) for a 32 bit build.

To address this in the short term, I added a flag that disables this
feature by default for now.

So, two questions:

1) What does everyone reckon the best solution to this is?
  * Keep the feature disabled by default - with a flag to enable it for
those who want it/can use it
  * Enable the feature everywhere - with a flag to disable it
  * Conditionally disable (or conditionally enable) the feature, with a
flag to enable/disable it
    * best condition we probably have is "disabled if 32 bit and
-ggnu-pubnames" (gnu-pubnames are necessary for efficient building of
gdb-index, and isn't the default)


FWIW, we use -Wl,--gdb-index but had never heard of -ggnu-pubnames before
last week and don't use it (yet?). So maybe just "32-bit".

Either of these options works for us. From a usability perspective
independent of chromium, making your linker not crash by default seems kind
of nice to me. But either of these options works for me. Disabling the
feature everywhere by default seems a bit strange since it has no known
drawbacks on 64-bit (yet? :-) ).

2) How to implement the flag:
  * backend option as it is currently (-mllvm
-use-dwarf-ranges-base-address-specifier
(maybe drop "-specifier" to make it a bit more terse))
  * clang option that maps to
    * backend option (as currently)
    * MCOption (programmatic/C++ API rather than command line of a backend
option)
    * LLVM IR attribute on the CU (this feature could be supported on a
per-CU basis easiyl enough, thus survive LTO, etc, exactly as the user
requested (but really if the user requested this on at least one CU, they
probably might as well have it on all their CUs))
    * LLVM IR module metadata


Any ideas/thoughts/other aspects?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170808/3bcf63f5/attachment.html>