From: Fangrui Song <maskray@google.com>
To: binutils@sourceware.org, gdb@sourceware.org,
elfutils-devel@sourceware.org
Subject: Re: Range lists, zero-length functions, linker gc
Date: Sun, 31 May 2020 12:15:32 -0700 [thread overview]
Message-ID: <20200531191532.albcdemzwbeyovik@google.com> (raw)
In-Reply-To: <20200531185506.mp2idyczc4thye4h@google.com>
On 2020-05-31, Fangrui Song wrote:
>It is being discussed on llvm-dev
>(https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html https://groups.google.com/forum/#!topic/llvm-dev/i0DFx6YSqDA)
>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
>
>---
>
>To save your time, I have a summary of the discussions. I am eager to know what you think
>of the ideas from binutils/gdb/elfutils's perspective.
>
>* {{reserved_address}} Paul Robinson wants to propose that DWARF v6 reserves a special address.
> All (undef + addend) in .debug_* are resolved to -1.
>
> We have to ignore the addend. With __attribute__((section(".text.x"))),
> the address offset pair may be something like [.text.x + 16, .text.x + 24)
> I have to resolve the whole (.text.x + 16) to the special value.
>
> (undef + addend) in pre-DWARF v5 .debug_loc and .debug_ranges are resolved to -2
> (0 and -1 cannot be used due to the reasons above).
>
>* Refined formula for a relocated value in a non-SHF_ALLOC section:
>
> if is_defined(sym)
> return addr(sym) + addend
> if relocated_section is .debug_ranges or .debug_loc
> return -2 # addend is intentionally ignored
>
> // Every DWARF v5 section falls here
> return -1 {{zero}}
>
>* {{zero}} Can we resolve (undef + addend) to 0?
>
> https://lists.llvm.org/pipermail/llvm-dev/2020-May/141967.html
>
> > while it might not be an issue for ELF, DWARF would want a standard that's fairly resilient to
> > quirky/interesting use cases (admittedly - such platforms could equally want to make their
> > executable code way up in the address space near max or max - 1, etc?).
>
> Question: is address 0 meaningful for code in some binary formats?
>
>* {{overlap}} The current situation (GNU ld, gold, LLD): (undef + addend) in .debug_* are resolved to addend.
> For an address offset pair like [.text + 0, .text + 0x10010), if the ending address offset is large
> enough, it may overlap with a normal text address range (for example [0x10000, *))
>
> This can cause problems in debuggers. How does gdb solve the problem?
>
>* {{nonalloc}} Linkers resolve (undef + addend) in non-SHF_ALLOC sections to
> `addend`. For non-debug sections (open-ended), do we have needs resolving such
> values to `base` or `base+addend` where base is customizable?
> (https://lists.llvm.org/pipermail/llvm-dev/2020-May/141956.html )
Forgot to mention
* {{compatibility}} Do we need an option if we change the computed value of (undef + addend) to
-2 (.debug_loc,.debug_ranges)/-1 (other .debug_*)
(or 0 (other .debug_*), but it might not be nice to some binary formats {{reserved_address}})
https://lists.llvm.org/pipermail/llvm-dev/2020-May/141958.html
> If we end up blessing it as part of the DWARF spec, we probably
> wouldn't want it to be user-configurable for the .debug_ sections, so
> I'd hesitate to add that configurability to the linker lest we have to
> revoke it to conform to DWARF (breaking flag compatibility with
> previous versions of the linker, etc). Admittedly we'll be breaking
> output compatibility with this change regardless, so potentially
> having the flag as an escape hatch could be useful.
I hope we don't need to have a linker option. But if some not-so-old
versions of gdb / binutils programs / elfutils programs can't cope
with -2/-1/0 {{reserved_address}}, we may have to invent a linker option.
I hope GNU ld, gold and LLD can have a compatible option.
(As an LLD contributor, I'd be happy to implement the opinion in LLD)
next prev parent reply other threads:[~2020-05-31 19:15 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 [this message]
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
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=20200531191532.albcdemzwbeyovik@google.com \
--to=maskray@google.com \
--cc=binutils@sourceware.org \
--cc=elfutils-devel@sourceware.org \
--cc=gdb@sourceware.org \
/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).