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

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>

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>

On Tue, Aug 8, 2017 at 7:43 AM Nico Weber <thakis at chromium.org> wrote:
> 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.
>
Ah, OK!

:/

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