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

[David Blaikie via llvm-dev]

On Tue, Aug 8, 2017 at 6:56 AM Nico Weber <thakis at chromium.org> wrote:

> 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?).
>

PR34007 about the gold failure shows -ggnu-pubnames in the repro, though?


> 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/a2111b97/attachment.html>