From: David Blaikie <dblaikie@gmail.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Fangrui Song <maskray@google.com>,
gdb@sourceware.org, elfutils-devel@sourceware.org,
binutils@sourceware.org
Subject: Re: Range lists, zero-length functions, linker gc
Date: Sun, 31 May 2020 13:49:12 -0700 [thread overview]
Message-ID: <CAENS6Esjx0HQpviW=ZrA4O3Bza7JDOpoqe3fLxqmLZ4TZsv-9w@mail.gmail.com> (raw)
In-Reply-To: <20200531201016.GJ44629@wildebeest.org>
On Sun, May 31, 2020 at 1:41 PM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi,
>
> On Sun, May 31, 2020 at 11:55:06AM -0700, Fangrui Song via Elfutils-devel wrote:
> > what linkers should do regarding relocations referencing dropped
> > functions (due to section group rules, --gc-sections, /DISCARD/,
> > etc) in .debug_*
> >
> > As an example:
> >
> > __attribute__((section(".text.x"))) void f1() { }
> > __attribute__((section(".text.x"))) void f2() { }
> > int main() { }
> >
> > Some .debug_* sections are relocated by R_X86_64_64 referencing
> > undefined symbols (the STT_SECTION symbols are collected):
> >
> > 0x00000043: DW_TAG_subprogram [2]
> > ###### relocated by .text.x + 10
> > DW_AT_low_pc [DW_FORM_addr] (0x0000000000000010 ".text.x")
> > DW_AT_high_pc [DW_FORM_data4] (0x00000006)
> > DW_AT_frame_base [DW_FORM_exprloc] (DW_OP_reg6 RBP)
> > DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0000002c] = "_Z2f2v")
> > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000033] = "f2")
> >
> >
> > With ld --gc-sections:
> >
> > * DW_AT_low_pc [DW_FORM_addr] in .debug_info are resolved to 0 +
> > addend This can cause overlapping address ranges with normal text
> > sections. {{overlap}} * [beginning address offset, ending address
> > offset) in .debug_ranges are resolved to 1 (ignoring addend). See
> > bfd/reloc.c (behavior introduced in
> > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4067dbb2a3368dbf908b39c5435c84d51abc9f3
> > )
> >
> > [0, 0) cannot be used because it terminates the list entry.
> > [-1, -1) cannot be used because -1 represents a base address
> > selection entry which will affect subsequent address offset
> > pairs.
> > * .debug_loc address offset pairs have similar problem to .debug_ranges
> > * In DWARF v5, the abnormal values can be in a separate section .debug_addr
> >
> > ---
> >
> > I am eager to know what you think
> > of the ideas from binutils/gdb/elfutils's perspective.
>
> I think this is a producer problem. If a (code) section can be totally
> dropped then the associated (.debug) sections should have been
> generated together with that (code) section in a COMDAT group. That
> way when the linker drops that section, all the associated sections in
> that COMDAT group will get dropped with it. If you don't do that, then
> the DWARF is malformed and there is not much a consumer can do about
> it.
>
> Said otherwise, I don't think it is correct for the linker (with
> --gc-sections) to drop any sections that have references to it
> (through relocation symbols) from other (.debug) sections.
That's probably not practical for at least some users - the
easiest/most thorough counter-example is Split DWARF - the DWARF is in
another file the linker can't see. All the linker sees is a list of
addresses (debug_addr).
All 3 linkers have (modulo bugs) supported this situation, to varying
degrees, for decades (ld.bfd: resolve to zero everywhere, resolve to 1
in debug_ranges, lld/gold: resolve to 0+addend) & this is an attempt
to fix the bugs & maybe make the solution a bit more robust/work for
more cases/be more intentional.
(even if not for Split DWARF - creating DWARF that can be dropped by a
non-DWARF-aware linker (ie: one that doesn't have to parse/rebuild all
the DWARF at link time - which would be super expensive (though
someone's prototyping that in lld for those willing to pay that
tradeoff)) involves larger DWARF which isn't always a great tradeoff -
some users care a lot more about object size than executable size (and
maybe increased link time - due to more sections, etc))
next prev parent reply other threads:[~2020-05-31 20:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-31 18:55 Fangrui Song
2020-05-31 19:15 ` Fangrui Song
2020-05-31 20:10 ` Mark Wielaard
2020-05-31 20:47 ` Fangrui Song
2020-05-31 22:11 ` Mark Wielaard
2020-05-31 23:17 ` David Blaikie
2020-05-31 20:49 ` David Blaikie [this message]
2020-05-31 22:29 ` Mark Wielaard
2020-05-31 22:36 ` David Blaikie
2020-06-01 9:31 ` Mark Wielaard
2020-06-01 20:18 ` David Blaikie
2020-06-02 16:50 ` Mark Wielaard
2020-06-02 18:06 ` David Blaikie
2020-06-03 3:10 ` Alan Modra
2020-06-03 4:06 ` Fangrui Song
2020-06-03 21:50 ` David Blaikie
2020-06-09 20:24 ` Tombstone values in debug sections (was: Range lists, zero-length functions, linker gc) Fangrui Song
2020-06-19 20:04 ` Mark Wielaard
2020-06-20 1:02 ` David Blaikie
2020-06-19 12:00 ` Range lists, zero-length functions, linker gc Mark Wielaard
2020-06-20 0:46 ` David Blaikie
2020-06-24 22:21 ` Mark Wielaard
2020-06-25 23:45 ` David Blaikie
2020-05-31 21:33 ` David Blaikie
2020-06-01 16:25 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAENS6Esjx0HQpviW=ZrA4O3Bza7JDOpoqe3fLxqmLZ4TZsv-9w@mail.gmail.com' \
--to=dblaikie@gmail.com \
--cc=binutils@sourceware.org \
--cc=elfutils-devel@sourceware.org \
--cc=gdb@sourceware.org \
--cc=mark@klomp.org \
--cc=maskray@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).