Re: [musl] Can’t build musl with lto=thin

[Jiahao XU <Jiahao_XU@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 8461 bytes --]

I tried to run “musl-clang -Oz -flto -s -static -fuse-ld=musl-clang-lld -Wl,—plugin-opt=O3,-O3 hello.c”, but it still doesn’t work.

Note that I have removed -static from ld.musl-clang-lld

Jiahao XU
________________________________
From: Rich Felker <dalias@libc.org>
Sent: Monday, February 1, 2021 8:01:06 AM
To: Jiahao XU <Jiahao_XU@outlook.com>
Cc: musl@lists.openwall.com <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 <dalias@libc.org>
> Sent: Sunday, January 31, 2021 4:01:22 PM
> To: Jiahao XU <Jiahao_XU@outlook.com>
> Cc: musl@lists.openwall.com <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 <decode_vec+21>
> >
> > 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 <decode_vec>
> >
> >    0x00007ffff7ff58cb <+28>:    mov    (%rbx),%rax
> >
> >
> > Disassembly of decode_vec:
> >
> >
> >    0x00007ffff7ff5483 <+0>:     xor    %eax,%eax
> >
> >    0x00007ffff7ff5485 <+2>:     cmp    $0x20,%rax
> >
> >    0x00007ffff7ff5489 <+6>:     je     0x7ffff7ff5495 <decode_vec+18>
> >
> >    0x00007ffff7ff548b <+8>:     andq   $0x0,(%rsi,%rax,8)
> >
> >    0x00007ffff7ff5490 <+13>:    inc    %rax
> >
> >    0x00007ffff7ff5493 <+16>:    jmp    0x7ffff7ff5485 <decode_vec+2>
> >
> >    0x00007ffff7ff5495 <+18>:    push   $0x1
> >
> >    0x00007ffff7ff5497 <+20>:    pop    %rax
> >
> > => 0x00007ffff7ff5498 <+21>:    mov    (%rdi),%rcx
> >
> >    0x00007ffff7ff549b <+24>:    test   %rcx,%rcx
> >
> >    0x00007ffff7ff549e <+27>:    je     0x7ffff7ff54c3 <decode_vec+64>
> >
> >    0x00007ffff7ff54a0 <+29>:    lea    -0x1(%rcx),%rdx
> >
> >    0x00007ffff7ff54a4 <+33>:    cmp    $0x1e,%rdx
> >
> >    0x00007ffff7ff54a8 <+37>:    ja     0x7ffff7ff54bd <decode_vec+58>
> >
> >    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 <decode_vec+21>
> >
> >    0x00007ffff7ff54c3 <+64>:    ret
> >
> >
> > Jiahao XU
> >
> > Get Outlook for iOS<https://aka.ms/o0ukef>
> > ________________________________
> > From: Rich Felker <dalias@libc.org>
> > Sent: Sunday, January 31, 2021 10:30:12 AM
> > To: Jiahao XU <Jiahao_XU@outlook.com>
> > Cc: musl@lists.openwall.com <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 <dalias@libc.org>
> > > Sent: Sunday, January 31, 2021 7:12:31 AM
> > > To: Jiahao XU <Jiahao_XU@outlook.com>
> > > Cc: musl@lists.openwall.com <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

[-- Attachment #2: Type: text/html, Size: 16449 bytes --]