Oleg Ranevskyy
2014-Sep-26 13:24 UTC
[LLVMdev] [lld] A primitive program linked by lld core dumps
Hi, I've encountered a newly introduced bug in lld today. I am building my program with clang and lld on an X86-64 Ubuntu Linux machine. Command line: clang main.c The compiled program invokes the "main" function multiple times until it closes with a segmentation fault. This affects even the most primitive programs like "int main() { return 0; }". The problem was introduced at the revision 218259 - [ELF] Fix linking when a regular object defines a symbol that is used in a DSO. Would you be able to take a look at this please? Thank you. Kind regards, Oleg
Rafael Auler
2014-Sep-26 13:32 UTC
[LLVMdev] [lld] A primitive program linked by lld core dumps
Thanks for reporting, I'll look into this. Could you send me in a private message the binary attached? Thanks, Rafael On Fri, Sep 26, 2014 at 10:24 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote:> Hi, > > I've encountered a newly introduced bug in lld today. > > I am building my program with clang and lld on an X86-64 Ubuntu Linux > machine. > Command line: > clang main.c > > The compiled program invokes the "main" function multiple times until it > closes with a segmentation fault. > This affects even the most primitive programs like "int main() { return 0; > }". > > The problem was introduced at the revision 218259 - [ELF] Fix linking when > a regular object defines a symbol that is used in a DSO. > > Would you be able to take a look at this please? > > Thank you. > > Kind regards, > Oleg >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/8c588b31/attachment.html>
Rafael Auler
2014-Sep-26 14:38 UTC
[LLVMdev] [lld] A primitive program linked by lld core dumps
Hi Oleg, The problem is that lld incorrectly exports a dummy definition of __tls_get_addr saying that this TLS runtime function resides at the first address of the text section (which coincides with your main function). Your libc (and mine doesn't, that's why this went unnoticed) requests this symbol at link time, and the linker promptly puts this into the dynamic symbol table. At runtime, your program runs normally, but afterwards, when libc is running its finalization hooks, it uses TLS storage, a mechanism that needs the __tls_get_addr function to be correctly set up. Since it has been incorrectly linked to your main function, it loops calling your main function several times until it crashes. Therefore, while the patch introduced in r218259 is correct, the problem is that lld is incorrectly exporting __tls_get_addr. I spent this week working on this issue (TLS relocations) and I will upload today a patch that fixes the __tls_get_addr symbol on ELF targets, please wait a little more until this new patch gets reviewed. Thanks for your report. Rafael Auler On Fri, Sep 26, 2014 at 10:32 AM, Rafael Auler <rafaelauler at gmail.com> wrote:> Thanks for reporting, I'll look into this. > > Could you send me in a private message the binary attached? > > Thanks, > Rafael > > On Fri, Sep 26, 2014 at 10:24 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com > > wrote: > >> Hi, >> >> I've encountered a newly introduced bug in lld today. >> >> I am building my program with clang and lld on an X86-64 Ubuntu Linux >> machine. >> Command line: >> clang main.c >> >> The compiled program invokes the "main" function multiple times until it >> closes with a segmentation fault. >> This affects even the most primitive programs like "int main() { return >> 0; }". >> >> The problem was introduced at the revision 218259 - [ELF] Fix linking >> when a regular object defines a symbol that is used in a DSO. >> >> Would you be able to take a look at this please? >> >> Thank you. >> >> Kind regards, >> Oleg >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/a490fce5/attachment.html>
Seemingly Similar Threads
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- Removed a call to EmitXRayTable() from ARMAsmPrinter