[llvm-dev] [LLD] Support DWARF64, debug_info "sorting"

Wed Nov 18 00:51:33 PST 2020

I was thinking about whether I liked the section name idea myself. I think
a slight refinement could be to have linkers combine .debug and .debug64
sections into one output section (in non -r links), so that end consumers
(debuggers etc) don't have to worry about it. However, conformance is still
a concern to me as we cannot really retrofit the existing standard
versions, and the section names themselves are in the standard. That means
that tools that otherwise would work might stop working when presented with
a "new" DWARFv3/4/5 output that it in theory could otherwise handle. This
applies to both debuggers who don't know about the support and tools like
llvm-dwarfdump which work on intermediate objects until they get updated.
One final concern with the section name approach is that there are tools
that look for the debug sections in general (e.g. llvm-objcopy
--strip-debug), which use the prefix ".debug_" to identify such sections,
rather than .debug, so .debug64 would be a bad name to use (although you
could do .debug_64_info or .debug_info_64 probably safely).

On Wed, 18 Nov 2020 at 06:07, Fāng-ruì Sòng <maskray at google.com> wrote:

> In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to
> join the group before making a post)
> Cary Coutant raised yet another idea: whether we can use ".debug64" as
> the section prefix. I like the idea because of:
>
> * It is immediately obvious whether DWARF64 is used and whether
> DWARF32 is used along with DWARF64.
> * In a relocatable link mixing DWARF32 and DWARF64 sections, DWARF32
> and DWARF64 sections will naturally not get mixed. (For a relocation
> based approach, if DWARF64 is the first input section, the output may
> appear as a "DWARF64" because the proposed approach only checks the
> first relocation)
>
> On the other hand,
>
> * It is (slightly) non-conformant because of the different section names.
> * Tooling support. Some commonly used consumers have recognized
> DWARF64. We'll have to teach these tools about new section names. The
> number of sections to recognize has doubled. This may result in a fair
> amount of complexity (DWARFContext/MCObjectFileInfo/llvm-dwarfdump
> -debug* options/ld.lld --gdb-index are things I can immediately think
> of).
>
> On balance I think this is not as good as the section type idea.
>
> On Tue, Nov 17, 2020 at 12:17 AM James Henderson
> <jh7370.2008 at my.bristol.ac.uk> wrote:
> >
> > Thinking about it, it would probably be wise to raise this discussion on
> the DWARF mailing list too. They might want to put an addendum in the
> spec/DWARF wiki/somewhere appropriate along the lines of "ELF support for
> DWARF64", which can be retroactively applied to existing standards. The
> committee may also have some thoughts on how tools are expected to work
> with DWARF64 and DWARF32 mixtures.
> >
> > James
> >
> > On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> wrote:
> >>
> >> On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com>
> wrote:
> >> >
> >> > On 14.11.2020 3:42, Fāng-ruì Sòng wrote:
> >> > > For .debug_* in object files:
> >> > >
> >> > > DWARF32 -> SHT_PROGBITS (unchanged)
> >> > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64
> >> > >
> >> > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If
> >> > > all input sections are SHT_DWARF64, the output section type probably
> >> > > should also be SHT_DWARF64.
> >> > > If mixed, SHT_PROGBITS.
> >> >
> >> > I am not really sure that we need a new section type. This gets a
> small
> >> > simplification in one part of the linker but adds much more burden of
> >> > supporting that to all tools and specs around. And that support would
> be
> >> > required for a rarely used feature, which certainly results that
> support
> >> > to be partial and sometimes erroneous.
> >>
> >> This is not a small simplification. If we consider how we would
> >> address .debug_str with the relocation approach,
> >> it would be quite contrived. A reply I just made
> >> https://lists.llvm.org/pipermail/llvm-dev/2020-November/146673.html
> >> detailed why I don't like the conceptual model: the behavior is
> >> dependent on other sections.
> >> I also felt bad as I had to do string comparison on ".debug_"
> >> (https://reviews.llvm.org/D91404)
> >>
> >> I've chatted with gdb folks: gdb (gdb/dwarf2/read.c) is agnostic about
> >> the section type. (They just cannot handle multiple .debug_info
> >> sections.)
> >> SHT_PROGBITS is a default (or "use this if nothing more specific
> >> exists") section type that probably no tool will specifically check
> >> the type.
> >> For many tools, they don't understand DWARF64 yet - there is little
> >> they need to adapt when they add DWARF64 support.
> >> Currently the only problem I can think of is readelf -S (from my
> >> understanding of
> >> https://sourceware.org/pipermail/binutils/2020-November/114116.html ,
> >> Nick will be happy if I write a GNU readelf patch to make the section
> >> header table dump look good:) )
> >>
> >> > If we aim for clarity and not ambiguity, I would suggest considering
> the
> >> > following. The DWARF specs designed so that the data of DWARF32 and
> >> > DWARF64 formats can be intermixed together in one section. What
> section
> >> > type should be used for that combination? Should it be another new
> >> > section type, something like SHT_DWARF32_DWARF64? Probably not, that
> >> > should be a regular SHT_PROGBITS. That means that DWARF64 data can be
> >> > contained in a SHT_PROGBITS section. Consequently, the section which
> >> > contains DWARF64 data without DWARF32 data should also be
> SHT_PROGBITS,
> >> > because the latter is just a special case of the former.
> >>
> >> I suggest we follow the `canMergeToProgbits` logic in LLD: mixed
> >> SHT_DWARF64 and SHT_PROGBITS get SHT_PROGBITS. This is the existing
> >> rule for many other section types.
> >> Conceptually, the combined section should impose the rigid restriction
> >> when it is further combined with other sections.
> >> This is probably an extra argument that we don't need SHT_DWARF32.
> >>
> >> > > FWIW I started a generic-abi thread
> >> > > https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ ("Reserve a
> >> > > section type value for DWARF64") to give stakeholders from other ELF
> >> > > operating systems a chance to participate in the design. I have paid
> >> > > attention to my wording: a new section type is **not decided yet**
> on
> >> > > LLVM/GNU binutils sides. Our discussions on llvm-dev/binutils will
> >> > > benefit from agreement/disagreement from generic-abi.
> >> >
> >> > Thank you for conducting all these discussions. I hope we will finally
> >> > find a way to bring the feature alive.
> >>
> >> Thanks to James and Pavel for quoting the standard.
> >> https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ
> >> It seems that we've made progress on the thread and may be able to get
> >> a generic value.
> >> I am following up with binutils folks
> >> https://sourceware.org/pipermail/binutils/2020-November/
> >> I hope we can get to a design which satisfies all parties.
> >>
> >>
> >> > --
> >> > Best Regards,
> >> > Igor Kudrin
> >> > C++ Developer, Access Softek, Inc.
> >>
> >>
> >>
> >> --
> >> 宋方睿
>
>
>
> --
> 宋方睿
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/cb30d730/attachment.html>