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

[Nico Weber via llvm-dev]

On Tue, Aug 8, 2017 at 10:41 AM, David Blaikie <dblaikie at gmail.com> wrote:

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

'cause you asked me to test with that on IRC :-) We don't use it in our
"real" build config.


>
>
>> 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/3dcbe075/attachment-0001.html>