[llvm-dev] Range lists, zero-length functions, linker gc

[James Henderson via llvm-dev]

On Mon, 1 Jun 2020 at 08:21, Alexey Lapshin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> >> Paul> As has been mentioned elsewhere, Sony generally fixes up
> references from
> >> Paul> debug info to stripped functions (of any length) using -1, because
> >> Paul> that’s a less-likely-to-be-real address than 0x0 or 0x1.  (0x0 is
> a
> >> Paul> typical base address for shared libraries, I’d think using it has
> the
> >> Paul> potential to mislead various consumers.)  For .debug_ranges we
> use -2,
> >> Paul> because both a 0/0 pair and a -1/-1 pair have a reserved meaning
> in that
> >> Paul> section.
> >>
> >> 0 in an ET_DYN object refers to the base address, where the ELF header
> >> (or headers of other binary formats) resides. The ELF header is unlikely
> >> to be a meaningful code sequence. In LLD and GNU ld -z separate-code's
> >> layout, it is mapped to a (non-executable) PF_R PT_LOAD segment.
> >>
> >> I suspect special cased 0 values may have been baked into some DWARF
> >> consumers.
> >>
> >> Do other binary formats/platforms allow the base address to be a
> >> meaningful place that we can't lose DWARF for? (If 0 is a meaningful
> >> place but its debuggability does not matter that much, we can still use
> >> 0 as a special value, losing the debuggability of address 0).
>
> >Yeah, that's the thing - 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?).
>
> >I know Alexey was particularly interested in the problem of
> >low-address functions overlapping with the [0, length) ranges created
> >by dead code with gold/lld - but I'm not sure if he has a use case for
> >literal zero, or just "low but non-zero". Hopefully he can weigh in
> >here.
>
> yes. Having 0 as valid executable address is a common case for embedded
> programs.
> Our customers have problems with overlapping address ranges like [0x00,
> length) and [0xf0, length).
> They use linker script to have .text starting from 0. I would consult for
> the real case and whether they have use case for literal zero. i.e. [0x00,
> length) and [0x00, length).
>
Just to add to what Alexey said, we have linker scripts that don't map the
file header and program header table to the address space, so our
executable data can start from address 0, at least statically, before ASLR
is applied. The loader just reads the file directly for information from
the headers, and the executable itself doesn't need or have access to the
data. At runtime of course, our addresses are non-zero, but since the debug
sections aren't dynamically relocated, the debugger does the adjustment
itself, meaning it handles address 0 references in debug data the same as
any other address. Consequently, even ignoring the 0/0 range issue, 0 can't
be used for us without ambiguity.

Also, a dead .debug_aranges entry for an empty function would end up with a
0/0 pair, terminating the range IIRC, if 0 were used/left, and that's not
DWARF v4 specific, so would need handling in a different way.


>
> Another thing is that at a time when D59553 was tested many tools worked
> incorrectly for  [0x00, length) and [0xf0, length) case.
> To properly handle that situation - [0x00, length) and [0xf0, length) and
> use 0 as a marker - there would be necessary to teach all of them to handle
> 0.
> At the same time, using -2 makes all of them working without modifications.
>
> Thank you, Alexey.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200601/d940e320/attachment.html>