[llvm-dev] DWARF: Anyone using global variable addresses in .debug_aranges?

[David Blaikie via llvm-dev]

On Wed, Oct 27, 2021 at 6:29 AM <paul.robinson at sony.com> wrote:

> Actually .debug_aranges is supposed to cover both code and (static/global)
> data.  DWARF v5 section 6.1.2, p.148 line 12 clearly says “text or data
> covered by some entry” so I’d say GCC has a bug there.
>

Yep, that is what the spec says - but I'm curious if anyone's depending on
this behavior/if that's a useful thing to do. If GCC's not doing it &
hasn't forever, it seems unlikely anyone's relying on Clang doing that.


> That said… if there’s no DIE with the range, according to spec it can be
> omitted from .debug_aranges;
>

I'm not sure that's the best thing for the spec to say, though - making it
expensive to go searching through all the CUs for line table entries if
that data wasn't communicated through CU DW_AT_ranges and aranges.

& I suspect the case of "line table describes instructions that aren't
covered by any subprogram" isn't really a scenario the spec intended to
cover in this wording - in which case we're a bit "off-spec" already, so
maybe we can decide what that means?


> is that what the gmlt optimization does?
>

It does.


> I think our backtrace printer might be assuming that .debug_aranges
> describes everything covered by .debug_line, which apparently is not the
> case if DIEs get omitted (or have their address ranges omitted).
>
> --paulr
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Tuesday, October 26, 2021 7:36 PM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>; Robinson, Paul <
> paul.robinson at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk>;
> Adrian Prantl <aprantl at apple.com>; Jonas Devlieghere <
> jdevlieghere at apple.com>
> *Subject:* DWARF: Anyone using global variable addresses in
> .debug_aranges?
>
>
>
> (I think we had some discussion about this a few years back, but can't
> seem to find it in my email)
>
> GCC doesn't put global variables/data into arranges, only functions/code -
> making arranges basically (entirely? so far as I know) the same as a CU's
> address range (high/low/ranges).
>
> Clang does put global variables in aranges. The whole arange content is
> driven by the emission of address attributes on DIEs.
>
> There's currently a bug (I introduced, someone else filed recently:
> https://bugs.llvm.org/show_bug.cgi?id=52187
> <https://urldefense.com/v3/__https:/bugs.llvm.org/show_bug.cgi?id=52187__;!!JmoZiZGBv3RvKRSx!tlBXtnd64BQMB7ocXsK4c4ix406Cn7chqYOkTvysFghb-mks3t0YDpVZj_TBzPTUmg$>)
> in aranges with gmlt caused by the highly minimal form of gmlt I
> implemented a few years ago that skips subprogram DIEs for subprograms with
> no inlining (they have enough info in the line table+symbol table to do
> good backtraces, so we can save space by skipping the subprogram
> description). But this means no address attributes are emitted for these
> functions, so they don't end up in the aranges table.
>
> I think it might be simpler to fix this issue by making aranges be
> identical to CU ranges - this would be consistent with GCC's use of
> aranges (omitting globals) & reduce the chance of bugs of trying to keep
> two different lists in LLVM's implementation.
>
> What do folks think?
>
> (caveat: aranges are off by default in Clang because they seem redundant
> with CU ranges - I really don't understand why anyone's using them and we
> don't use them at Google... but bugs is bugs I guess)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211027/cc7c832e/attachment.html>