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

Tue Aug 8 10:57:15 PDT 2017

On Tue, Aug 8, 2017 at 10:50 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> Can gdb handle these?  i.e. is it just gold that has the problem?
>

Yep, it's just gold when it's building the gdb-index (an accelerator table
for GDB)

>   Conditioning on debugger tuning when it's not the debugger that has the
> problem… icky.
>

It does. Though to a lesser degree even gnu-pubnames isn't a perfect
signal. One, I think, could use that even without a linker-generated
gdb-index - presumably GDB's still faster by reading gnu-pubnames than by
reading the raw DIEs to do lookup.

>   If that's the case then asking people to add –ggnu-pubnames seems okay.
> Assuming that gets handed down through IR/metadata then the LTO problem
> goes away too.
>

gnu-pubnames has such problems (it's done as a backend option, passed down
from the clang driver via -mllvm -generate-gnu-dwarf-pub-sections, but
they're already there... - mostly the discussion around flags was "If we're
adding a new one, what's the right tradeoff here for a workaround flag
compared to the platonic ideals of CU-based flags as much as possible") but
it's already that way...

- Dave

> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Tuesday, August 08, 2017 10:59 AM
> *To:* Robinson, Paul; llvm-dev; Adrian Prantl; Eric Christopher; Nico
> Weber
> *Subject:* Re: DWARF: Ranges base address specifier entries & Gold's
> gdb-index 32 bit bug
>
>
>
> Adrian: any thoughts? Has LLDB been fixed to support this yet?
>
> On Tue, Aug 8, 2017 at 6:33 AM Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
> My inclination would be to use "disable if 32-bit and –ggnu-pubnames" as
> the default,
>
>
> Unfortunately Nico points out that Chrome doesn't currently use
> -ggnu-pubnames :/ So to continue to work "out of the box" we'd have to
> broaden the surface to "disable if 32 bit and targeting gdb".
>
> -ggnu-pubnames makes gdb-index creation much more efficient by allowing
> gdb-index generation not to have to parse most of the DWARF DIEs, and just
> create the index straight from a table. (this is necessary for correctness
> in -gsplit-dwarf mode (where the DIEs are not available at link time as
> they're in the .dwo not the .o), and an efficiency gain otherwise)
>
> If "disable if 32 bit and targeting gdb" is overly broad (I feel it kind
> of is, but I'm not wedded to it) we could require those working around the
> gold bug to add -ggnu-pubnames to add a bit more of a specific hint that
> they're intending to build gdb-index from these objects.
>
>
> and have a flag.
>
> This would be determined in DwarfDebug, right?
>
>
> Yes
>
>
> If the check is in CodeGen then I'd think it would be insensitive to LTO.
>
>
> There's some desire that LTO works as-if it was non-LTO. So if you pass
> flags (eg: debugger tuning flags, in this case) to each separate compile,
> you get the same behavior if you LTO as when you didn't - so we preserve
> things in the CU, and then do the specified thing per-CU. (eg: emission
> kind (gmlt/limited/full), split-debug-inlining, debug-info-for-profiling,
> etc)
>
> In this case if, say, you're on an LLDB platform but prefer to use GDB (&
> happen to use Gold and gdb-index on 32 bit and LTO) - so you pass the
> debugger tuning=gdb flag to your compiles, it wouldn't disable the feature,
> because the flag would be consulted at CodeGen time and not at compile time
> when you passed the tuning flag. (oh, actually the tuning is passed down
> via TM Options anyway, not on the CU - so I guess you wouldn't be getitng
> the tuning at all today because that flag already doesn't follow the per-CU
> model... well I guess that makes it easier)
>
>
> Setting it via IR/metadata is adding a bunch of complexity just to work
> around a gold bug.  Not worth it IMO.
>
>
> Fair enough. Any thoughts on whether it should be a frontend-visible
> option or just a cc1 or even backend option? I'll probably just leave it as
> a backend option at this point, could even implement the defaulting down in
> LLVM without any changes to Clang, I suppose...
>
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Monday, August 07, 2017 6:58 PM
> *To:* llvm-dev; Robinson, Paul; Adrian Prantl; Eric Christopher; Nico
> Weber
> *Subject:* DWARF: Ranges base address specifier entries & Gold's
> gdb-index 32 bit bug
>
>
>
> 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)
> 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/fdbcc06e/attachment.html>