<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Jun 2020 at 08:21, Alexey Lapshin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
>> Paul> As has been mentioned elsewhere, Sony generally fixes up references from<br>
>> Paul> debug info to stripped functions (of any length) using -1, because<br>
>> Paul> that’s a less-likely-to-be-real address than 0x0 or 0x1.  (0x0 is a<br>
>> Paul> typical base address for shared libraries, I’d think using it has the<br>
>> Paul> potential to mislead various consumers.)  For .debug_ranges we use -2,<br>
>> Paul> because both a 0/0 pair and a -1/-1 pair have a reserved meaning in that<br>
>> Paul> section.<br>
>><br>
>> 0 in an ET_DYN object refers to the base address, where the ELF header<br>
>> (or headers of other binary formats) resides. The ELF header is unlikely<br>
>> to be a meaningful code sequence. In LLD and GNU ld -z separate-code's<br>
>> layout, it is mapped to a (non-executable) PF_R PT_LOAD segment.<br>
>><br>
>> I suspect special cased 0 values may have been baked into some DWARF<br>
>> consumers.<br>
>><br>
>> Do other binary formats/platforms allow the base address to be a<br>
>> meaningful place that we can't lose DWARF for? (If 0 is a meaningful<br>
>> place but its debuggability does not matter that much, we can still use<br>
>> 0 as a special value, losing the debuggability of address 0).<br>
<br>
>Yeah, that's the thing - while it might not be an issue for ELF, DWARF<br>
>would want a standard that's fairly resilient to quirky/interesting<br>
>use cases (admittedly - such platforms could equally want to make<br>
>their executable code way up in the address space near max or max - 1,<br>
etc?).<br>
<br>
>I know Alexey was particularly interested in the problem of<br>
>low-address functions overlapping with the [0, length) ranges created<br>
>by dead code with gold/lld - but I'm not sure if he has a use case for<br>
>literal zero, or just "low but non-zero". Hopefully he can weigh in<br>
>here.<br>
<br>
yes. Having 0 as valid executable address is a common case for embedded programs.<br>
Our customers have problems with overlapping address ranges like [0x00, length) and [0xf0, length).<br>
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).<br></blockquote><div>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.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another thing is that at a time when D59553 was tested many tools worked incorrectly for  [0x00, length) and [0xf0, length) case.<br>
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.<br>
At the same time, using -2 makes all of them working without modifications.<br>
<br>
Thank you, Alexey.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>