llvm dev - Oct 2021 - 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) 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/20211026/d95117fc/attachment.html>

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.

That said… if there’s no DIE with the range, according to spec it can be omitted
from .debug_aranges; is that what the gmlt optimization 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/bf29a8a8/attachment.html>