Rui Ueyama via llvm-dev
2017-Mar-15 16:50 UTC
[llvm-dev] [LLD] Linking static library does not resolve symbols as gold/ld
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. So, what you are seeing is likely a bug of LLD that it fails to fix the address for some reason. 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. On Wed, Mar 15, 2017 at 9:25 AM, Martin Richtarsky <s at martinien.de> wrote:> Hi all, > > I'm currently trying out lld on a large project. We are currently using > gold (and used GNU ld before that). > > I have come across a few minor issues but could workaround them: > - Missing support for --defsym=symbol1=symbol2, > --warn-unknown-eh-frame-section, --exclude-libs > > There are two other issues which are more critical, one of which is > currently blocking me, so I would like to find a solution for this one > first. > > I have a static library that is linked into an executable. The binary > produced by lld crashes, while the gold version runs fine. > > The difference is in the call instructions below. The original object file > from the archive has an address of zero in the call instruction: > > 0000000000013832 <func>: > 13832: 55 push %rbp > 13833: 48 89 e5 mov %rsp,%rbp > 13836: 53 push %rbx > 13837: 48 83 ec 18 sub $0x18,%rsp > 1383b: 48 89 7d e8 mov %rdi,-0x18(%rbp) > 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > 13843: 48 89 c7 mov %rax,%rdi > -> 13846: e8 00 00 00 00 callq 1384b <func+0x19> > 1384b: 48 8b 45 e8 mov -0x18(%rbp),%rax > > gdb displays this as a jump to the next instruction: > > 0x0000000000013832 <+0>: push %rbp > 0x0000000000013833 <+1>: mov %rsp,%rbp > 0x0000000000013836 <+4>: push %rbx > 0x0000000000013837 <+5>: sub $0x18,%rsp > 0x000000000001383b <+9>: mov %rdi,-0x18(%rbp) > 0x000000000001383f <+13>: mov -0x18(%rbp),%rax > 0x0000000000013843 <+17>: mov %rax,%rdi > 0x0000000000013846 <+20>: callq 0x1384b <func()+25> > 0x000000000001384b <+25>: mov -0x18(%rbp),%rax > > However, in the executable linked by gold, the calls are magically > resolved: > > 0x000000000018b44e <+0>: push %rbp > 0x000000000018b44f <+1>: mov %rsp,%rbp > 0x000000000018b452 <+4>: push %rbx > 0x000000000018b453 <+5>: sub $0x18,%rsp > 0x000000000018b457 <+9>: mov %rdi,-0x18(%rbp) > 0x000000000018b45b <+13>: mov -0x18(%rbp),%rax > 0x000000000018b45f <+17>: mov %rax,%rdi > 0x000000000018b462 <+20>: callq 0x68568c <std::vector<record, > std::allocator<record> >::vector()> > 0x000000000018b467 <+25>: mov -0x18(%rbp),%rax > > Even more interesting, several such call instructions with argument 0 are > resolved to different functions. So somewhere there must be information > stored to what functions they resolve to. > > lld produces this code: > > 0x00005555559f304e <+0>: push %rbp > 0x00005555559f304f <+1>: mov %rsp,%rbp > 0x00005555559f3052 <+4>: push %rbx > 0x00005555559f3053 <+5>: sub $0x18,%rsp > 0x00005555559f3057 <+9>: mov %rdi,-0x18(%rbp) > 0x00005555559f305b <+13>: mov -0x18(%rbp),%rax > 0x00005555559f305f <+17>: mov %rax,%rdi > 0x00005555559f3062 <+20>: callq 0x555555554000 > 0x00005555559f3067 <+25>: mov -0x18(%rbp),%rax > > 0x555555554000 is the start of the mapped region of the executable, so it > seems lld just adds the argument 0 to that without doing any relocation > processing. > > Is this a known limitation of lld? > > Thanks and best regards, > Martin >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/aef980b7/attachment.html>
Martin Richtarsky via llvm-dev
2017-Mar-15 21:22 UTC
[llvm-dev] [LLD] Linking static library does not resolve symbols as gold/ld
Here is the relevant output:
0000000000013832 <func()>:
13832: 55 push %rbp
13833: 48 89 e5 mov %rsp,%rbp
13836: 53 push %rbx
13837: 48 83 ec 18 sub $0x18,%rsp
1383b: 48 89 7d e8 mov %rdi,-0x18(%rbp)
1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax
13843: 48 89 c7 mov %rax,%rdi
13846: e8 00 00 00 00 callq 1384b <func()+0x19>
13847: R_X86_64_PLT32 std::vector<record,
std::allocator<record> >::vector()-0x4
....
Let me know if more is needed.
I recall that this object file is created in a bit unusual way, something
like partially linking several other object files together into this one,
but I will have to dig deeper to say for sure.
Best regards
Martin
Rui Ueyama wrote:> 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.
>
> So, what you are seeing is likely a bug of LLD that it fails to fix the
> address for some reason.
>
> 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.
>
> On Wed, Mar 15, 2017 at 9:25 AM, Martin Richtarsky <s at
martinien.de> wrote:
>
>> Hi all,
>>
>> I'm currently trying out lld on a large project. We are currently
using
>> gold (and used GNU ld before that).
>>
>> I have come across a few minor issues but could workaround them:
>> - Missing support for --defsym=symbol1=symbol2,
>> --warn-unknown-eh-frame-section, --exclude-libs
>>
>> There are two other issues which are more critical, one of which is
>> currently blocking me, so I would like to find a solution for this one
>> first.
>>
>> I have a static library that is linked into an executable. The binary
>> produced by lld crashes, while the gold version runs fine.
>>
>> The difference is in the call instructions below. The original object
>> file
>> from the archive has an address of zero in the call instruction:
>>
>> 0000000000013832 <func>:
>> 13832: 55 push %rbp
>> 13833: 48 89 e5 mov %rsp,%rbp
>> 13836: 53 push %rbx
>> 13837: 48 83 ec 18 sub $0x18,%rsp
>> 1383b: 48 89 7d e8 mov %rdi,-0x18(%rbp)
>> 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax
>> 13843: 48 89 c7 mov %rax,%rdi
>> -> 13846: e8 00 00 00 00 callq 1384b
<func+0x19>
>> 1384b: 48 8b 45 e8 mov -0x18(%rbp),%rax
>>
>> gdb displays this as a jump to the next instruction:
>>
>> 0x0000000000013832 <+0>: push %rbp
>> 0x0000000000013833 <+1>: mov %rsp,%rbp
>> 0x0000000000013836 <+4>: push %rbx
>> 0x0000000000013837 <+5>: sub $0x18,%rsp
>> 0x000000000001383b <+9>: mov %rdi,-0x18(%rbp)
>> 0x000000000001383f <+13>: mov -0x18(%rbp),%rax
>> 0x0000000000013843 <+17>: mov %rax,%rdi
>> 0x0000000000013846 <+20>: callq 0x1384b <func()+25>
>> 0x000000000001384b <+25>: mov -0x18(%rbp),%rax
>>
>> However, in the executable linked by gold, the calls are magically
>> resolved:
>>
>> 0x000000000018b44e <+0>: push %rbp
>> 0x000000000018b44f <+1>: mov %rsp,%rbp
>> 0x000000000018b452 <+4>: push %rbx
>> 0x000000000018b453 <+5>: sub $0x18,%rsp
>> 0x000000000018b457 <+9>: mov %rdi,-0x18(%rbp)
>> 0x000000000018b45b <+13>: mov -0x18(%rbp),%rax
>> 0x000000000018b45f <+17>: mov %rax,%rdi
>> 0x000000000018b462 <+20>: callq 0x68568c
<std::vector<record,
>> std::allocator<record> >::vector()>
>> 0x000000000018b467 <+25>: mov -0x18(%rbp),%rax
>>
>> Even more interesting, several such call instructions with argument 0
>> are
>> resolved to different functions. So somewhere there must be information
>> stored to what functions they resolve to.
>>
>> lld produces this code:
>>
>> 0x00005555559f304e <+0>: push %rbp
>> 0x00005555559f304f <+1>: mov %rsp,%rbp
>> 0x00005555559f3052 <+4>: push %rbx
>> 0x00005555559f3053 <+5>: sub $0x18,%rsp
>> 0x00005555559f3057 <+9>: mov %rdi,-0x18(%rbp)
>> 0x00005555559f305b <+13>: mov -0x18(%rbp),%rax
>> 0x00005555559f305f <+17>: mov %rax,%rdi
>> 0x00005555559f3062 <+20>: callq 0x555555554000
>> 0x00005555559f3067 <+25>: mov -0x18(%rbp),%rax
>>
>> 0x555555554000 is the start of the mapped region of the executable, so
>> it
>> seems lld just adds the argument 0 to that without doing any relocation
>> processing.
>>
>> Is this a known limitation of lld?
>>
>> Thanks and best regards,
>> Martin
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Rui Ueyama via llvm-dev
2017-Mar-15 22:13 UTC
[llvm-dev] [LLD] Linking static library does not resolve symbols as gold/ld
On Wed, Mar 15, 2017 at 2:22 PM, Martin Richtarsky <s at martinien.de> wrote:> Here is the relevant output: > > 0000000000013832 <func()>: > 13832: 55 push %rbp > 13833: 48 89 e5 mov %rsp,%rbp > 13836: 53 push %rbx > 13837: 48 83 ec 18 sub $0x18,%rsp > 1383b: 48 89 7d e8 mov %rdi,-0x18(%rbp) > 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > 13843: 48 89 c7 mov %rax,%rdi > 13846: e8 00 00 00 00 callq 1384b <func()+0x19> > 13847: R_X86_64_PLT32 std::vector<record, > std::allocator<record> >::vector()-0x4 > .... >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. Let me know if more is needed.> > I recall that this object file is created in a bit unusual way, something > like partially linking several other object files together into this one, > but I will have to dig deeper to say for sure. >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.> Best regards > Martin > > Rui Ueyama wrote: > > 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. > > > > So, what you are seeing is likely a bug of LLD that it fails to fix the > > address for some reason. > > > > 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. > > > > On Wed, Mar 15, 2017 at 9:25 AM, Martin Richtarsky <s at martinien.de> > wrote: > > > >> Hi all, > >> > >> I'm currently trying out lld on a large project. We are currently using > >> gold (and used GNU ld before that). > >> > >> I have come across a few minor issues but could workaround them: > >> - Missing support for --defsym=symbol1=symbol2, > >> --warn-unknown-eh-frame-section, --exclude-libs > >> > >> There are two other issues which are more critical, one of which is > >> currently blocking me, so I would like to find a solution for this one > >> first. > >> > >> I have a static library that is linked into an executable. The binary > >> produced by lld crashes, while the gold version runs fine. > >> > >> The difference is in the call instructions below. The original object > >> file > >> from the archive has an address of zero in the call instruction: > >> > >> 0000000000013832 <func>: > >> 13832: 55 push %rbp > >> 13833: 48 89 e5 mov %rsp,%rbp > >> 13836: 53 push %rbx > >> 13837: 48 83 ec 18 sub $0x18,%rsp > >> 1383b: 48 89 7d e8 mov %rdi,-0x18(%rbp) > >> 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > >> 13843: 48 89 c7 mov %rax,%rdi > >> -> 13846: e8 00 00 00 00 callq 1384b <func+0x19> > >> 1384b: 48 8b 45 e8 mov -0x18(%rbp),%rax > >> > >> gdb displays this as a jump to the next instruction: > >> > >> 0x0000000000013832 <+0>: push %rbp > >> 0x0000000000013833 <+1>: mov %rsp,%rbp > >> 0x0000000000013836 <+4>: push %rbx > >> 0x0000000000013837 <+5>: sub $0x18,%rsp > >> 0x000000000001383b <+9>: mov %rdi,-0x18(%rbp) > >> 0x000000000001383f <+13>: mov -0x18(%rbp),%rax > >> 0x0000000000013843 <+17>: mov %rax,%rdi > >> 0x0000000000013846 <+20>: callq 0x1384b <func()+25> > >> 0x000000000001384b <+25>: mov -0x18(%rbp),%rax > >> > >> However, in the executable linked by gold, the calls are magically > >> resolved: > >> > >> 0x000000000018b44e <+0>: push %rbp > >> 0x000000000018b44f <+1>: mov %rsp,%rbp > >> 0x000000000018b452 <+4>: push %rbx > >> 0x000000000018b453 <+5>: sub $0x18,%rsp > >> 0x000000000018b457 <+9>: mov %rdi,-0x18(%rbp) > >> 0x000000000018b45b <+13>: mov -0x18(%rbp),%rax > >> 0x000000000018b45f <+17>: mov %rax,%rdi > >> 0x000000000018b462 <+20>: callq 0x68568c <std::vector<record, > >> std::allocator<record> >::vector()> > >> 0x000000000018b467 <+25>: mov -0x18(%rbp),%rax > >> > >> Even more interesting, several such call instructions with argument 0 > >> are > >> resolved to different functions. So somewhere there must be information > >> stored to what functions they resolve to. > >> > >> lld produces this code: > >> > >> 0x00005555559f304e <+0>: push %rbp > >> 0x00005555559f304f <+1>: mov %rsp,%rbp > >> 0x00005555559f3052 <+4>: push %rbx > >> 0x00005555559f3053 <+5>: sub $0x18,%rsp > >> 0x00005555559f3057 <+9>: mov %rdi,-0x18(%rbp) > >> 0x00005555559f305b <+13>: mov -0x18(%rbp),%rax > >> 0x00005555559f305f <+17>: mov %rax,%rdi > >> 0x00005555559f3062 <+20>: callq 0x555555554000 > >> 0x00005555559f3067 <+25>: mov -0x18(%rbp),%rax > >> > >> 0x555555554000 is the start of the mapped region of the executable, so > >> it > >> seems lld just adds the argument 0 to that without doing any relocation > >> processing. > >> > >> Is this a known limitation of lld? > >> > >> Thanks and best regards, > >> Martin > >> > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://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/20170315/a4194bc5/attachment.html>
Apparently Analagous Threads
- [LLD] Linking static library does not resolve symbols as gold/ld
- [LLD] Linking static library does not resolve symbols as gold/ld
- [LLD] Linking static library does not resolve symbols as gold/ld
- [Bug 14192] New: nouveau on NV17: screen remains black with randr12 on
- [Bug 13843] New: swfplay: Fatal IO error 104 (Connection reset by peer) on X server