I have finally succeded to produce a statically linked hello_world executable. I modified the last line of musl-clang-lld to: exec $($cc -print-prog-name=ld.lld) -nostdlib “$@“ -l:libc.a —no-dynamic-linker and everything works fine now. Jiahao XU ________________________________ From: Rich Felker Sent: Monday, February 1, 2021 8:01:06 AM To: Jiahao XU Cc: musl@lists.openwall.com Subject: Re: [musl] Can’t build musl with lto=thin On Sun, Jan 31, 2021 at 05:32:45AM +0000, Jiahao XU wrote: > I used `musl-clang -Oz -flto -s -fuse-ld=musl-clang-lld-static -Wl,—plugin-opt=O3,-O3 hello.c` to produce the executable. Where is -static? Normally it does *not* work to add -static just to the ld command line. The compiler driver has to know that it's requesting static linking because it will pass a different command line to the linker based on that. > Content of `/usr/local/musl/bin/ld.musl-clang-lld-static` is same as > the generated `ld.musl-clang`, except for the last line, which I > modified it to: > > exec $($cc -print-prog-name=ld.lld) -nostdlib “$@“ -static -lc -dynamic-linker “$ldso” Try moving -static out from here (i.e. using the script unmodified except for requesting ld.lld) and see if that works. Note that a correctly linked executable will not have any INTERP in readelf -a output, so as long as you see INTERP anywhere there you're doing something wrong. Rich > ________________________________ > From: Rich Felker > Sent: Sunday, January 31, 2021 4:01:22 PM > To: Jiahao XU > Cc: musl@lists.openwall.com > Subject: Re: [musl] Can’t build musl with lto=thin > > On Sat, Jan 30, 2021 at 11:44:48PM +0000, Jiahao XU wrote: > > (gdb) bt > > > > #0 0x00007ffff7ff5498 in decode_vec () from /lib/ld-musl-x86_64.so.1 > > > > #1 0x00007ffff7ff58cb in decode_dyn () from /lib/ld-musl-x86_64.so.1 > > > > #2 0x0000000000000000 in ?? () > > This is not a static-linked program. decode_dyn is part of the dynamic > linker. It looks to me like you've created some sort of weird hybrid > executable that's not valid. Can you show the command lines you used > to produce it? > > Also please keep list on CC when replying. > > Rich > > > > (gdb) info r > > > > rax 0x1 1 > > > > rbx 0x7ffff7ffe2d8 140737354130136 > > > > rcx 0x5000 20480 > > > > rdx 0x200238 2097720 > > > > rsi 0x7fffffffd8d0 140737488345296 > > > > rdi 0x0 0 > > > > rbp 0x7ffff7ffe2d8 0x7ffff7ffe2d8 <__dls3.app> > > > > rsp 0x7fffffffd8c8 0x7fffffffd8c8 > > > > r8 0x0 0 > > > > r9 0xfffffffffffff000 -4096 > > > > r10 0x800000 8388608 > > > > r11 0x200000 2097152 > > > > r12 0x7fffffffdcb8 140737488346296 > > > > r13 0x0 0 > > > > r14 0x7fffffffd8d0 140737488345296 > > > > r15 0x7fffffffdcb8 140737488346296 > > > > rip 0x7ffff7ff5498 0x7ffff7ff5498 > > > > eflags 0x10246 [ PF ZF IF RF ] > > > > cs 0x33 51 > > > > ss 0x2b 43 > > > > ds 0x0 0 > > > > es 0x0 0 > > > > fs 0x0 0 > > > > gs 0x0 0 > > > > > > Disassembly of decode_dyn: > > > > > > 0x00007ffff7ff58af <+0>: push %r14 > > > > 0x00007ffff7ff58b1 <+2>: push %rbx > > > > 0x00007ffff7ff58b2 <+3>: sub $0x108,%rsp > > > > 0x00007ffff7ff58b9 <+10>: mov %rdi,%rbx > > > > 0x00007ffff7ff58bc <+13>: mov 0x10(%rdi),%rdi > > > > 0x00007ffff7ff58c0 <+17>: mov %rsp,%r14 > > > > 0x00007ffff7ff58c3 <+20>: mov %r14,%rsi > > > > 0x00007ffff7ff58c6 <+23>: call 0x7ffff7ff5483 > > > > 0x00007ffff7ff58cb <+28>: mov (%rbx),%rax > > > > > > Disassembly of decode_vec: > > > > > > 0x00007ffff7ff5483 <+0>: xor %eax,%eax > > > > 0x00007ffff7ff5485 <+2>: cmp $0x20,%rax > > > > 0x00007ffff7ff5489 <+6>: je 0x7ffff7ff5495 > > > > 0x00007ffff7ff548b <+8>: andq $0x0,(%rsi,%rax,8) > > > > 0x00007ffff7ff5490 <+13>: inc %rax > > > > 0x00007ffff7ff5493 <+16>: jmp 0x7ffff7ff5485 > > > > 0x00007ffff7ff5495 <+18>: push $0x1 > > > > 0x00007ffff7ff5497 <+20>: pop %rax > > > > => 0x00007ffff7ff5498 <+21>: mov (%rdi),%rcx > > > > 0x00007ffff7ff549b <+24>: test %rcx,%rcx > > > > 0x00007ffff7ff549e <+27>: je 0x7ffff7ff54c3 > > > > 0x00007ffff7ff54a0 <+29>: lea -0x1(%rcx),%rdx > > > > 0x00007ffff7ff54a4 <+33>: cmp $0x1e,%rdx > > > > 0x00007ffff7ff54a8 <+37>: ja 0x7ffff7ff54bd > > > > 0x00007ffff7ff54aa <+39>: shlx %rcx,%rax,%rcx > > > > 0x00007ffff7ff54af <+44>: or %rcx,(%rsi) > > > > 0x00007ffff7ff54b2 <+47>: mov (%rdi),%rcx > > > > 0x00007ffff7ff54b5 <+50>: mov 0x8(%rdi),%rdx > > > > 0x00007ffff7ff54b9 <+54>: mov %rdx,(%rsi,%rcx,8) > > > > 0x00007ffff7ff54bd <+58>: add $0x10,%rdi > > > > 0x00007ffff7ff54c1 <+62>: jmp 0x7ffff7ff5498 > > > > 0x00007ffff7ff54c3 <+64>: ret > > > > > > Jiahao XU > > > > Get Outlook for iOS > > ________________________________ > > From: Rich Felker > > Sent: Sunday, January 31, 2021 10:30:12 AM > > To: Jiahao XU > > Cc: musl@lists.openwall.com > > Subject: Re: [musl] Can’t build musl with lto=thin > > > > On Sat, Jan 30, 2021 at 11:04:32PM +0000, Jiahao XU wrote: > > > > So something like (in config.mak): > > > > > > > > obj/ldso/dlstart.lo: CFLAGS_ALL += -fno-lto > > > > > > Thanks, with this I was able to build libc.so successfully with clang and created a 3.5 KB hello world program using clang and lld. > > > > > > However, I still wasn’t able to statically linked with libc. > > > > > > Once I added ‘-static’ to the compiler flags, the executable failed with ‘Segmentation fault (core dumped)’. > > > > It's libc.a, not libc.so, that will be involved in making a > > static-linked binary. It's hard to know what's going wrong without > > more information. Can you run under a debugger and provide a > > backtrace, disassembly, and register dump for where the crash occurs? > > > > Rich > > > > > > > ________________________________ > > > From: Rich Felker > > > Sent: Sunday, January 31, 2021 7:12:31 AM > > > To: Jiahao XU > > > Cc: musl@lists.openwall.com > > > Subject: Re: [musl] Can’t build musl with lto=thin > > > > > > On Fri, Jan 29, 2021 at 12:19:42PM +0000, Jiahao XU wrote: > > > > musl-1.2.2 compilation with clang-11 failed to build libc.so at the final linking stage: > > > > > > > > ld.lld: error: undefined hidden symbol: __dls2 > > > > >>> referenced by ld-temp.o > > > > >>> lto.tmp:(_dlstart_c) > > > > >>> did you mean: __dls3 > > > > >>> defined in: lto.tmp > > > > > > > > I am using CFLAGS=‘-march=native -mtune=native -Oz -flto > > > > -fmerge-all-constants -fomit-frame-pointer’ and LDFLAGS=‘-flto > > > ^^^^^^^^^^^^^^^^^^^^^ > > > > > > The -fmerge-all-constants option gives non-conforming language > > > semantics and should not be used, but that's a separate issue. > > > > > > > -fuse-ld=lld -Wl,—plugin-opt=O3,-O3,—icf=safe’. > > > > > > > No configure option is supplied. > > > > > > Otherwise, it's a known issue that LTO misses references from asm > > > (both top-level and in functions). I think dlstart.lo and a few other > > > files should just be built with LTO disabled; any LTO-type > > > optimization in code that runs at this stage is inherently invalid, > > > anyway. So something like (in config.mak): > > > > > > obj/ldso/dlstart.lo: CFLAGS_ALL += -fno-lto > > > > > > Rich