<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 15, 2017 at 2:22 PM, 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">Here is the relevant output:<br>
<br>
0000000000013832 <func()>:<br>
<span class=""> 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>
</span> 13846: e8 00 00 00 00 callq 1384b <func()+0x19><br>
13847: R_X86_64_PLT32 std::vector<record,<br>
std::allocator<record> >::vector()-0x4<br>
....<br></blockquote><div><br></div><div>This seems a bit odd. You have type `record` and instantiate std::vector with `record`. Usually the instantiated template function is in the same compilation unit, and the relocation type is R_X86_64_PC32, not R_X86_64_PLT32.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me know if more is needed.<br>
<br>
I recall that this object file is created in a bit unusual way, something<br>
like partially linking several other object files together into this one,<br>
but I will have to dig deeper to say for sure.<br></blockquote><div><br></div><div>Yes, it looks like the object file is created in an unusual way, and that revealed a subtle difference between ld.gold and ld.lld. I want to know more about that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best regards<br>
Martin<br>
<div><div class="h5"><br>
Rui Ueyama wrote:<br>
> Compilers don't know about functions that are not defined in the same<br>
> compilation unit, so they leave call instruction operands as zero (because<br>
> they can't compute any absolute nor relative address of the destinations),<br>
> and let linkers fix the address by binary patching.<br>
><br>
> So, what you are seeing is likely a bug of LLD that it fails to fix the<br>
> address for some reason.<br>
><br>
> Can you dump that function with `objdump -d -r that-file.o`? With the -r<br>
> option, objdump prints out relocation records. Relocation records are the<br>
> information that linkers use to fix addresses.<br>
><br>
> On Wed, Mar 15, 2017 at 9:25 AM, Martin Richtarsky <<a href="mailto:s@martinien.de">s@martinien.de</a>> wrote:<br>
><br>
>> 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<br>
>> 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<br>
>> 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<br>
>> 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<br>
>> 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>
>><br>
</div></div>> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div><br></div></div>