<div dir="ltr"><div class="gmail_extra">Compilers don't know about functions that are not defined in the same compilation unit, so they leave call instruction operands as zero (because they can't compute any absolute nor relative address of the destinations), and let linkers fix the address by binary patching.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, what you are seeing is likely a bug of LLD that it fails to fix the address for some reason.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Can you dump that function with `objdump -d -r that-file.o`? With the -r option, objdump prints out relocation records. Relocation records are the information that linkers use to fix addresses.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 15, 2017 at 9:25 AM, Martin Richtarsky <span dir="ltr"><<a href="mailto:s@martinien.de" target="_blank">s@martinien.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'm currently trying out lld on a large project. We are currently using<br>
gold (and used GNU ld before that).<br>
<br>
I have come across a few minor issues but could workaround them:<br>
- Missing support for --defsym=symbol1=symbol2,<br>
--warn-unknown-eh-frame-<wbr>section, --exclude-libs<br>
<br>
There are two other issues which are more critical, one of which is<br>
currently blocking me, so I would like to find a solution for this one<br>
first.<br>
<br>
I have a static library that is linked into an executable. The binary<br>
produced by lld crashes, while the gold version runs fine.<br>
<br>
The difference is in the call instructions below. The original object file<br>
from the archive has an address of zero in the call instruction:<br>
<br>
0000000000013832 <func>:<br>
   13832:       55                      push   %rbp<br>
   13833:       48 89 e5                mov    %rsp,%rbp<br>
   13836:       53                      push   %rbx<br>
   13837:       48 83 ec 18             sub    $0x18,%rsp<br>
   1383b:       48 89 7d e8             mov    %rdi,-0x18(%rbp)<br>
   1383f:       48 8b 45 e8             mov    -0x18(%rbp),%rax<br>
   13843:       48 89 c7                mov    %rax,%rdi<br>
-> 13846:       e8 00 00 00 00          callq  1384b <func+0x19><br>
   1384b:       48 8b 45 e8             mov    -0x18(%rbp),%rax<br>
<br>
gdb displays this as a jump to the next instruction:<br>
<br>
   0x0000000000013832 <+0>:     push   %rbp<br>
   0x0000000000013833 <+1>:     mov    %rsp,%rbp<br>
   0x0000000000013836 <+4>:     push   %rbx<br>
   0x0000000000013837 <+5>:     sub    $0x18,%rsp<br>
   0x000000000001383b <+9>:     mov    %rdi,-0x18(%rbp)<br>
   0x000000000001383f <+13>:    mov    -0x18(%rbp),%rax<br>
   0x0000000000013843 <+17>:    mov    %rax,%rdi<br>
   0x0000000000013846 <+20>:    callq  0x1384b <func()+25><br>
   0x000000000001384b <+25>:    mov    -0x18(%rbp),%rax<br>
<br>
However, in the executable linked by gold, the calls are magically resolved:<br>
<br>
   0x000000000018b44e <+0>:     push   %rbp<br>
   0x000000000018b44f <+1>:     mov    %rsp,%rbp<br>
   0x000000000018b452 <+4>:     push   %rbx<br>
   0x000000000018b453 <+5>:     sub    $0x18,%rsp<br>
   0x000000000018b457 <+9>:     mov    %rdi,-0x18(%rbp)<br>
   0x000000000018b45b <+13>:    mov    -0x18(%rbp),%rax<br>
   0x000000000018b45f <+17>:    mov    %rax,%rdi<br>
   0x000000000018b462 <+20>:    callq  0x68568c <std::vector<record,<br>
std::allocator<record> >::vector()><br>
   0x000000000018b467 <+25>:    mov    -0x18(%rbp),%rax<br>
<br>
Even more interesting, several such call instructions with argument 0 are<br>
resolved to different functions. So somewhere there must be information<br>
stored to what functions they resolve to.<br>
<br>
lld produces this code:<br>
<br>
   0x00005555559f304e <+0>:     push   %rbp<br>
   0x00005555559f304f <+1>:     mov    %rsp,%rbp<br>
   0x00005555559f3052 <+4>:     push   %rbx<br>
   0x00005555559f3053 <+5>:     sub    $0x18,%rsp<br>
   0x00005555559f3057 <+9>:     mov    %rdi,-0x18(%rbp)<br>
   0x00005555559f305b <+13>:    mov    -0x18(%rbp),%rax<br>
   0x00005555559f305f <+17>:    mov    %rax,%rdi<br>
   0x00005555559f3062 <+20>:    callq  0x555555554000<br>
   0x00005555559f3067 <+25>:    mov    -0x18(%rbp),%rax<br>
<br>
0x555555554000 is the start of the mapped region of the executable, so it<br>
seems lld just adds the argument 0 to that without doing any relocation<br>
processing.<br>
<br>
Is this a known limitation of lld?<br>
<br>
Thanks and best regards,<br>
Martin<br>
</blockquote></div><br></div></div>