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 32183 invoked from network); 1 Feb 2021 11:46:00 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Feb 2021 11:46:00 -0000 Received: (qmail 7913 invoked by uid 550); 1 Feb 2021 11:45:47 -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 5892 invoked from network); 1 Feb 2021 00:45:03 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y/5ZTmDFY56z/q8dlwtwfThkz1obyPx/Qm/TbqRlCrqAmcDVt5/2rPqWB3Q2Jp32T54VnYSeSYzGRnb+ADUtFJg9UXg4qrTjuiIBBUOeu/L5lHvyarPO2nCDfdTzxQruHZt+nBitbfJke4mcbP5gOY84cjeB/jpSKH4QLZlfDpXD3RkgEV5o+z/i/vHtVZdjk9oB2e6NkcCwVITm1Asivrg/iJS3a448ogjn3HWH4m5bnmOo16d3V5OCgD2TBtUyrXxAFxUlbcI5keXYSrTZjhdsJCTLoDOyu7b17VIahxn6DznLK14AByBrGaAkJLXRq2WO/DV5EtP8ITeBub1r2w== 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=Ga0ny5lp7zEguv+yNE8ylzIa30KLgVp5Dgyu/rkBESo=; b=JP3tDi2L1buTNeiMxSl6l5rBy4XHAwqD6/dvYAMbBkZKYuIaJAbWDzx5j9n3oLACBbxfBzaWCmBh5XlwkdlJshamEjUu8iEALfzONACLMiMM+g3d4na9e5D7Eeok4xk9OWnJ0JWShW22NVZEjIfxtM/6T6oMfq2hTzYjkNY6pyVR3KA7E9aEnoEwQtMU4V4nAbwwfL5NnQThMX/C7ud+CbV8N33tv9NOn8ZM5WbsWl4JIoOgDK9JvmflEfZlbOB1sanohWdMPwHCgNw4e0IgCXEVLOkGzcqOjjCiK96LMgbG0pjjSr2SHmB4LAXrFBqdXdpaX5msh2cNIDT44WNbog== 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=Ga0ny5lp7zEguv+yNE8ylzIa30KLgVp5Dgyu/rkBESo=; b=smEfdkPKqje/flDbnk9mFAbb2/HhGVJSus2gq6CzgNkoHf2wzeCw0CDNDw4Sswsa034L/4gWHAHsczF/KTve/J5fy5EBtDDe5vDprC8499Xm9jOygeY74eQQvhDe9nohTaCRcmD+Gpt+Nte4o6i/lMFGXu2rfpcfuikriOef00ox8uT1dQ3UE6i1OcVhFfHpu5P8MkL+z7vFHyU/bxYTB4bX6Efow6sxQikGj75wcC9RmcNdTGOpgZODiC0o1bb5788Q3D/E/wgtXjLDOL8Vl/d/Sh31pQryXhGxHOW36xZoLvpP9/T986o/IY84nQZUWEZgYn67BXWLFPlt7k12EQ== 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/YAABVPD Date: Mon, 1 Feb 2021 00:44:49 +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:C58A45970CD38D26B10BF267E5B1E5AB9299604A20576EEE35FD1296A98E7B67;UpperCasedChecksum:37F50B6C59FDE3BDC18CBCE053F76573545B8947528D603AFE04C96F17C01F46;SizeAsReceived:7564;Count:44 x-tmn: [fToZdGC8XJm5BzyIpFVuXzO6Umf8ydf5] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 4d41ee63-db62-40d3-5fce-08d8c64a9495 x-ms-traffictypediagnostic: HK2APC01HT068: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RoSIcBIC4p8ke5tcAWz2cgMzQlKq5G3Q22s7AQ7hRqAUIZlYvxJ3DG1gVkcFHnt+h2hVqsqoZvi8/2mADpdXcC9jrNPWbn3XtB0TFMhl1qmXtb8fgrjmLkyKX2tKs2cPhgyesRxYKzAgggo11YBDvBa7XNRzrGSPjS3DqqcRj1wc4Efyz5L7vrFj0NYbUCVxZEsNDU3gaI6rE7eYWHFoAN0LauZaRU/bBPr69/SmpAn/5Plq7VfE3SM4jxPVA2/1aBEWjIMgIAVuALT5qmZjscyJBG25hVoyppgLoc94RvzI7DkGyaDjm1McMn0AkMykiQFcxISvieL4H+AwHTokgssX9+epQFi6Pp4BXV0ALrrM9xKzLjYEplrNhUDBshOGSR5vFagXvz440QcSyB4EnO0H//Uvc1io9EVUTj+kxGMoohKN3AsloFtKbCzsjJ0N x-ms-exchange-antispam-messagedata: kvf1aHUFFVPt+k0kzXKydrosCGWucFz1NkiPKXJm2Y5QjITeIgXRcvReU7TBM0IY+9Wlpw3omBEm/1wx7bWHVk5BlD0l+sHFHYkmROE5TSMgMdqAn4pzEqJ8ssp4eZxXQhdXHKZtJVFVk7uFq6ek0A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SYBP282MB02029BB58835B4909F7D04938AB69SYBP282MB0202AUSP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT057.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 4d41ee63-db62-40d3-5fce-08d8c64a9495 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2021 00:44:49.4472 (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: HK2APC01HT068 Subject: =?Windows-1252?Q?Re:_[musl]_Can=92t_build_musl_with_lto=3Dthin?= --_000_SYBP282MB02029BB58835B4909F7D04938AB69SYBP282MB0202AUSP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Correction: The executable is cut from 48KB to 8KB. I mixed up the numbers from du and ls. Jiahao XU ________________________________ From: Jiahao XU Sent: Monday, February 1, 2021 11:31:47 AM To: Rich Felker Cc: musl@lists.openwall.com Subject: Re: [musl] Can=92t build musl with lto=3Dthin 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_SYBP282MB02029BB58835B4909F7D04938AB69SYBP282MB0202AUSP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Correction: The executable is cut from 48KB to 8KB.

I mixed up the numbers from du and ls.

Jiahao XU

From: Jiahao XU <Jiahao_= XU@outlook.com>
Sent: Monday, February 1, 2021 11:31:47 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
 
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 = -flto is able to cut .text from 25.4 KiB to 3.04 KiB, and cut the .rodata f= rom 19.5 KiB to 120 bytes.
.data section however, seen an increase from 316 bytes to 372 bytes, bu= t the VM size is cut from 252 to 244 bytes.

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

    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]]                    =      

 -7= 2.7%      -8  [ =3D ]       0    [Unmapped]                      = ;        

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

 -9= 9.4% -19.4Ki -99.7% -19.4Ki    .rodata               =                  

 -8= 8.0% -22.3Ki -88.2% -22.3Ki    .text                &= nbsp;                  =

 -8= 9.4% -41.8Ki -88.5% -41.8Ki    TOTAL



Jiahao XU

From: Jiahao XU <Jiaha= o_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 <d= alias@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, Jiah= ao 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_SYBP282MB02029BB58835B4909F7D04938AB69SYBP282MB0202AUSP_--