From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32156 invoked from network); 1 Feb 2021 11:45:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Feb 2021 11:45:52 -0000 Received: (qmail 7682 invoked by uid 550); 1 Feb 2021 11:45:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3619 invoked from network); 1 Feb 2021 00:32:09 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X90A4g+EODBqGvpdEfGtI1zZeHAx9A1cO3B274Kii3Z4iMoq0Lj78KPdn8m2zgwcwEVwn++SR+QK1o7axn1WDrZap4zAwDXPgvx0CqYDqhpWhvAyYzR99wu1601igRdBezQ/D8zf89GsSPTjZT7GQB+wZ3jKentS7nIDrqkEAbmhRykAWmOZyhT24GwOE/HX7dAbIwFqg8bRHeBG6HJKCkvmctxKSjqbi/UWyHX1mwKCc+SH1Pmu8IcbkA+Zfjz0PGZsNoSjROQ3CCh/7TL360aUrphvOtbHGexnJeZNMvHn8ZID1CxtSNRJO3leFUwqZxmcZVe1tEeSCvw+ItEUQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NfwFUCpTn8eCw2cMquP0uDyog6CmULvd5tdz7yw88RI=; b=fpUyu8uXDxWSGlP1o8+q9RUgWWsWlnyd+cT9qtCqNeW8RdJpH+H8+oFEtN1AZE4EVGJqT/qjyfL1SQg7G8Ov5EJVxPkpwV91rCulNZdKdTig4+qK7YG2WBKCWw40kz1AczpMN1/hx+L7CC+dgbCCzOMwbkavFvnk1mRqn3m1rAgMKr67velpjqK9lPs3UR86uNWX2f5xMBVD5zRxfOTHTU49rCpXVaUwFHeEng2EMPgxcXSKW4JYAZWNsCwu53R0L6dWf69JnUHyZSZBl6BOzYAWwAKjzq5cOgGd8uoi+gG7hO6RYOlHg9Vzk19HmiuCGh+wKCnwGiG8wotp/gDyuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NfwFUCpTn8eCw2cMquP0uDyog6CmULvd5tdz7yw88RI=; b=NF9Vm/E85iy+ByEyulNpY4Muv0ewzYTOJlXP6MGUuVZUbbF7nVBh4FsHiyVuWvn0Lz4csOeT26CEYMwdA3wsYsCBaUBDGIX6wfUcy9v3WtUWdHsJAtcmJ8EpRDuuYTuZFbVaClxjdSmLq5j33pylqgESE16Efh0pkBRrIJn5O6/cic+t3dVSUoXs4QILqP4H5BoqcdfqmtJJH+BYo2gWmHCSFMxabMv31kkSTT2zof2CN2IFaJ8W5Iwnzuk2GSGwruFhN7jea98croDQSLuSJCG+fGQ+MeOQTd+QbFqF1i4UUIJPpn8Gf0NyPG2Fs3wXLioVFKh1w6brF2hQIrom3w== From: Jiahao XU To: Rich Felker CC: "musl@lists.openwall.com" Thread-Topic: =?Windows-1252?Q?[musl]_Can=92t_build_musl_with_lto=3Dthin?= Thread-Index: AQHW9jgSvzPebfQPWE+aIHYKw/I+pqpAnAqAgAAvdNWAAAfHAIAAA9LIgABYtQCAAAdvOIABBLYAgAA3oZ2AAAFi/Q== Date: Mon, 1 Feb 2021 00:31:47 +0000 Message-ID: References: <20210130201227.GP23432@brightrain.aerifal.cx> <20210130233012.GR23432@brightrain.aerifal.cx> <20210131050121.GS23432@brightrain.aerifal.cx> ,<20210131210105.GT23432@brightrain.aerifal.cx>, In-Reply-To: Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:75171EF7DA41CCF02CBF9281D59C1DBAB9F531C0FB0AA81404E25F15C6AC1EAC;UpperCasedChecksum:9496E77ADB35CAA471B378F5091F71BF4FD7763224E9B2FD92374E120AB62CD5;SizeAsReceived:7498;Count:44 x-tmn: [4W5eFy4Dn/NmiJUTTBfR8FDnF9VLE/s7] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 8b72a737-c5d1-4b94-c447-08d8c648c280 x-ms-traffictypediagnostic: HK2APC01HT045: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lUgo8O+7SVQkz0yHQguM3/NdI3TaeAJlq292ihDgpo4zJ1TDT9uFzqrLyJyfBdRpZlX1FLtsjsUqe3r8mm9mdqf1iF+3sXHuFSerQtRejJuR3OlM+X/Fof3EPs8UZ/VZ8V++pZVbCV0lJ3zZz41m97q1y7NPM74Z5pltnAlZylSSWFvAzSy0NDZzt4U9juFQb8knKiRDQv0FGVIt3mbsDjpKW68mvrSguVQYvwXaMk+4OttV5QgnUb/EjDPPqsJA0/qBOcCaNCSmE6VV0r5ZErfCGlH0CzbbjJ0XN9oxbS+x4LBIB5AP087cB4gNVakmX1QIcgLznmML7P9ax3Z9np0ax2TKhhSvPRIXp3+gcbNmOwUB4jiVmhQ6gWNZvsSRksaIKofaDVfwDwz6lRKRN+beshjvX1soYt4KoecpmQXP/00ayYC9i8VMq3Rhf/Il x-ms-exchange-antispam-messagedata: NmVuvJmvUcC6vi5x7a2Yyhv2lEdO7JegNwpT1t2v4M36jF2BRSdzre3YYadqwenL+G7WLBGEsZuTd4YI/mlF524Ov50u/NEbDJjHuPYxben+kUXaCxn98Q0Xfarr4t+4nG4MF2hzLlN4mH5ewmR0Lg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SYBP282MB0202DA65BCEC9C92A459768B8AB69SYBP282MB0202AUSP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT064.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 8b72a737-c5d1-4b94-c447-08d8c648c280 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2021 00:31:47.5199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT045 Subject: =?Windows-1252?Q?Re:_[musl]_Can=92t_build_musl_with_lto=3Dthin?= --_000_SYBP282MB0202DA65BCEC9C92A459768B8AB69SYBP282MB0202AUSP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Interesting enough, I found =97gc-section used along with -flto can cut the= size of final hello_world executable from 48KB to 5KB. After investigating with bloaty, I found that =97gc-section along with -flt= o is able to cut .text from 25.4 KiB to 3.04 KiB, and cut the .rodata from = 19.5 KiB to 120 bytes. .data section however, seen an increase from 316 bytes to 372 bytes, but th= e VM size is cut from 252 to 244 bytes. $ bloaty gc-section-a.out -- no-gc-section.a.out FILE SIZE VM SIZE -------------- -------------- +18% +56 -3.2% -8 .data [NEW] +6 [NEW] +6 [LOAD #2 [RX]] [DEL] -4 -66.7% -8 [LOAD #4 [RW]] -72.7% -8 [ =3D ] 0 [Unmapped] -32.0% -64 [ =3D ] 0 .comment -99.4% -19.4Ki -99.7% -19.4Ki .rodata -88.0% -22.3Ki -88.2% -22.3Ki .text -89.4% -41.8Ki -88.5% -41.8Ki TOTAL Jiahao XU ________________________________ From: Jiahao XU Sent: Monday, February 1, 2021 11:22:21 AM To: Rich Felker Cc: musl@lists.openwall.com Subject: Re: [musl] Can=92t build musl with lto=3Dthin I have finally succeded to produce a statically linked hello_world executab= le. I modified the last line of musl-clang-lld to: exec $($cc -print-prog-name=3Dld.lld) -nostdlib =93$@=93 -l:libc.a =97n= o-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=92t build musl with lto=3Dthin On Sun, Jan 31, 2021 at 05:32:45AM +0000, Jiahao XU wrote: > I used `musl-clang -Oz -flto -s -fuse-ld=3Dmusl-clang-lld-static -Wl,=97p= lugin-opt=3DO3,-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=3Dld.lld) -nostdlib =93$@=93 -static -lc = -dynamic-linker =93$ldso=94 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=92t build musl with lto=3Dthin > > 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 > > > > =3D> 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=92t build musl with lto=3Dthin > > > > 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 +=3D -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=92t able to statically linked with libc. > > > > > > Once I added =91-static=92 to the compiler flags, the executable fail= ed with =91Segmentation fault (core dumped)=92. > > > > 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=92t build musl with lto=3Dthin > > > > > > 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=3D=91-march=3Dnative -mtune=3Dnative -Oz -flto > > > > -fmerge-all-constants -fomit-frame-pointer=92 and LDFLAGS=3D=91-flt= o > > > ^^^^^^^^^^^^^^^^^^^^^ > > > > > > The -fmerge-all-constants option gives non-conforming language > > > semantics and should not be used, but that's a separate issue. > > > > > > > -fuse-ld=3Dlld -Wl,=97plugin-opt=3DO3,-O3,=97icf=3Dsafe=92. > > > > > > > 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 +=3D -fno-lto > > > > > > Rich --_000_SYBP282MB0202DA65BCEC9C92A459768B8AB69SYBP282MB0202AUSP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Interesting enough, I found =97gc-section used along with -flto can cut the= size of final hello_world executable from 48KB to 5KB.

After investigating with bloaty, I found that =97gc-section along with -flt= o is able to cut .text from 25.4 KiB to 3.04 KiB, and cut the .rodata from = 19.5 KiB to 120 bytes.
.data section however, seen an increase from 316 bytes to 372 bytes, but th= e VM size is cut from 252 to 244 bytes.

$ bloaty gc-secti= on-a.out -- no-gc-section.a.out  

  &nbs= p; FILE SIZE        VM SIZE &nbs= p;                     &n= bsp;                     =  

 --------------  --------------             =                     &nbs= p;        

  = ; +18%     +56  -3.2%&n= bsp;     -8    .data                &= nbsp;                  =

  [NEW]      +6  [NEW]      +6    [LOAD #2 [RX]]              = ;            

  [DEL]      -4 -66.7%    =   -8    [LOAD #4 [RW]]                    =      

 -72.7%      -8  [ =3D ]       0    [Unmapped]                      = ;        

 -32.0%     -64  [ =3D ]   &nbs= p;   0    .comment                    =            

 -99.4% -19.4Ki -99.7% -19.4Ki    .rodata               =                  

 -88.0% -22.3Ki -88.2% -22.3Ki    .text                &= nbsp;                  =

 -89.4% -41.8Ki -88.5% -41.8Ki    TOTAL



Jiahao XU
From: Jiahao XU <Jiahao_= XU@outlook.com>
Sent: Monday, February 1, 2021 11:22:21 AM
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com <musl@lists.openwall.com>
Subject: Re: [musl] Can=92t build musl with lto=3Dthin
 
I have finally succeded to produce a statically linked hello_world exec= utable.

I modified the last line of musl-clang-lld to:
    
    exec $($cc -print-prog-name=3Dld.lld) -nostdlib =93$@=93 = -l:libc.a =97no-dynamic-linker

and everything works fine now.

Jiahao XU
From: Rich Felker <dal= ias@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=92t build musl with lto=3Dthin
 
On Sun, Jan 31, 2021 at 05:32:45AM +0000, Jiahao= XU wrote:
> I used `musl-clang -Oz -flto -s -fuse-ld=3Dmusl-clang-lld-static -Wl,= =97plugin-opt=3DO3,-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=3Dld.lld) -nostdli= b =93$@=93 -static -lc -dynamic-linker =93$ldso=94

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=92t build musl with lto=3Dthin
>
> On Sat, Jan 30, 2021 at 11:44:48PM +0000, Jiahao XU wrote:
> > (gdb) bt
> >
> > #0  0x00007ffff7ff5498 in decode_vec () from /lib/ld-musl-x8= 6_64.so.1
> >
> > #1  0x00007ffff7ff58cb in decode_dyn () from /lib/ld-musl-x8= 6_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          &n= bsp; 0x1           &= nbsp;     1
> >
> > rbx          &n= bsp; 0x7ffff7ffe2d8      140737354130136
> >
> > rcx          &n= bsp; 0x5000          &nbs= p;   20480
> >
> > rdx          &n= bsp; 0x200238          &n= bsp; 2097720
> >
> > rsi          &n= bsp; 0x7fffffffd8d0      140737488345296
> >
> > rdi          &n= bsp; 0x0           &= nbsp;     0
> >
> > rbp          &n= bsp; 0x7ffff7ffe2d8      0x7ffff7ffe2d8 <__dls3= .app>
> >
> > rsp          &n= bsp; 0x7fffffffd8c8      0x7fffffffd8c8
> >
> > r8          &nb= sp;  0x0          &n= bsp;      0
> >
> > r9          &nb= sp;  0xfffffffffffff000  -4096
> >
> > r10          &n= bsp; 0x800000          &n= bsp; 8388608
> >
> > r11          &n= bsp; 0x200000          &n= bsp; 2097152
> >
> > r12          &n= bsp; 0x7fffffffdcb8      140737488346296
> >
> > r13          &n= bsp; 0x0           &= nbsp;     0
> >
> > r14          &n= bsp; 0x7fffffffd8d0      140737488345296
> >
> > r15          &n= bsp; 0x7fffffffdcb8      140737488346296
> >
> > rip          &n= bsp; 0x7ffff7ff5498      0x7ffff7ff5498 <decode= _vec+21>
> >
> > eflags         0x10246&nb= sp;            [ PF = ZF IF RF ]
> >
> > cs          &nb= sp;  0x33          &= nbsp;     51
> >
> > ss          &nb= sp;  0x2b          &= nbsp;     43
> >
> > ds          &nb= sp;  0x0          &n= bsp;      0
> >
> > es          &nb= sp;  0x0          &n= bsp;      0
> >
> > fs          &nb= sp;  0x0          &n= bsp;      0
> >
> > gs          &nb= sp;  0x0          &n= bsp;      0
> >
> >
> > Disassembly of decode_dyn:
> >
> >
> >    0x00007ffff7ff58af <+0>:   = ;  push   %r14
> >
> >    0x00007ffff7ff58b1 <+2>:   = ;  push   %rbx
> >
> >    0x00007ffff7ff58b2 <+3>:   = ;  sub    $0x108,%rsp
> >
> >    0x00007ffff7ff58b9 <+10>:  &nbs= p; mov    %rdi,%rbx
> >
> >    0x00007ffff7ff58bc <+13>:  &nbs= p; mov    0x10(%rdi),%rdi
> >
> >    0x00007ffff7ff58c0 <+17>:  &nbs= p; mov    %rsp,%r14
> >
> >    0x00007ffff7ff58c3 <+20>:  &nbs= p; mov    %r14,%rsi
> >
> >    0x00007ffff7ff58c6 <+23>:  &nbs= p; call   0x7ffff7ff5483 <decode_vec>
> >
> >    0x00007ffff7ff58cb <+28>:  &nbs= p; 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>:  &nbs= p; inc    %rax
> >
> >    0x00007ffff7ff5493 <+16>:  &nbs= p; jmp    0x7ffff7ff5485 <decode_vec+2>
> >
> >    0x00007ffff7ff5495 <+18>:  &nbs= p; push   $0x1
> >
> >    0x00007ffff7ff5497 <+20>:  &nbs= p; pop    %rax
> >
> > =3D> 0x00007ffff7ff5498 <+21>:    mov&nbs= p;   (%rdi),%rcx
> >
> >    0x00007ffff7ff549b <+24>:  &nbs= p; test   %rcx,%rcx
> >
> >    0x00007ffff7ff549e <+27>:  &nbs= p; je     0x7ffff7ff54c3 <decode_vec+64>
> >
> >    0x00007ffff7ff54a0 <+29>:  &nbs= p; lea    -0x1(%rcx),%rdx
> >
> >    0x00007ffff7ff54a4 <+33>:  &nbs= p; cmp    $0x1e,%rdx
> >
> >    0x00007ffff7ff54a8 <+37>:  &nbs= p; ja     0x7ffff7ff54bd <decode_vec+58>
> >
> >    0x00007ffff7ff54aa <+39>:  &nbs= p; shlx   %rcx,%rax,%rcx
> >
> >    0x00007ffff7ff54af <+44>:  &nbs= p; or     %rcx,(%rsi)
> >
> >    0x00007ffff7ff54b2 <+47>:  &nbs= p; mov    (%rdi),%rcx
> >
> >    0x00007ffff7ff54b5 <+50>:  &nbs= p; mov    0x8(%rdi),%rdx
> >
> >    0x00007ffff7ff54b9 <+54>:  &nbs= p; mov    %rdx,(%rsi,%rcx,8)
> >
> >    0x00007ffff7ff54bd <+58>:  &nbs= p; add    $0x10,%rdi
> >
> >    0x00007ffff7ff54c1 <+62>:  &nbs= p; jmp    0x7ffff7ff5498 <decode_vec+21>
> >
> >    0x00007ffff7ff54c3 <+64>:  &nbs= p; 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=92t build musl with lto=3Dthin
> >
> > 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 +=3D -fno-lto
> > >
> > > Thanks, with this I was able to build libc.so successfully w= ith clang and created a 3.5 KB hello world program using clang and lld.
> > >
> > > However, I still wasn=92t able to statically linked with lib= c.
> > >
> > > Once I added =91-static=92 to the compiler flags, the execut= able failed with =91Segmentation fault (core dumped)=92.
> >
> > 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 withou= t
> > more information. Can you run under a debugger and provide a
> > backtrace, disassembly, and register dump for where the crash occ= urs?
> >
> > 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><= br> > > > Subject: Re: [musl] Can=92t build musl with lto=3Dthin
> > >
> > > On Fri, Jan 29, 2021 at 12:19:42PM +0000, Jiahao XU wrote: > > > > musl-1.2.2 compilation with clang-11 failed to build li= bc.so at the final linking stage:
> > > >
> > > >     ld.lld: error: undefined hidden= symbol: __dls2
> > > >     >>> referenced by ld-t= emp.o
> > > >     >>>   &= nbsp;           &nbs= p;          lto.tmp:(_dlstart_= c)
> > > >     >>> did you mean: __dl= s3
> > > >     >>> defined in: lto.tm= p
> > > >
> > > > I am using CFLAGS=3D=91-march=3Dnative -mtune=3Dnative = -Oz -flto
> > > > -fmerge-all-constants -fomit-frame-pointer=92 and LDFLA= GS=3D=91-flto
> > >   ^^^^^^^^^^^^^^^^^^^^^
> > >
> > > The -fmerge-all-constants option gives non-conforming langua= ge
> > > semantics and should not be used, but that's a separate issu= e.
> > >
> > > > -fuse-ld=3Dlld -Wl,=97plugin-opt=3DO3,-O3,=97icf=3Dsafe= =92.
> > >
> > > > No configure option is supplied.
> > >
> > > Otherwise, it's a known issue that LTO misses references fro= m 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 i= nvalid,
> > > anyway. So something like (in config.mak):
> > >
> > > obj/ldso/dlstart.lo: CFLAGS_ALL +=3D -fno-lto
> > >
> > > Rich
--_000_SYBP282MB0202DA65BCEC9C92A459768B8AB69SYBP282MB0202AUSP_--