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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29215 invoked from network); 3 Jan 2022 07:05:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2022 07:05:44 -0000 Received: (qmail 13964 invoked by uid 550); 3 Jan 2022 07:05:42 -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 13932 invoked from network); 3 Jan 2022 07:05:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1641193530; bh=kmL363t1XHxoHSoKZKqyWgyfgJBopo8QQFLud6R0ssw=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=UWlWUaYMs40ymSS712joS6a2L1p/axCptTuhzg4BRIL2ZeUZ2/H/O1HDsucqc0TZd JwxXdxCStNcehOEohXmJsnixBWSapRiDKR58MCpHmc3iNAyR9orMmkSF7haZH/hu74 glwsJWbZEHTvFGnyT8lsItZU6IT0VYL5KGpjRqP4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 3 Jan 2022 08:05:27 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220103070527.GB2629@voyager> References: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk> <98176a37-92c6-0da5-c14a-f61b4f8b13ec@m-labs.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98176a37-92c6-0da5-c14a-f61b4f8b13ec@m-labs.hk> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:8onIvDU/aGbzechCRyZceIVCUqFa7dDkmfNydXF+rlVAIQNkGgg lXhxD0GD+SuUuwDLzJW6in7fgiJhGz3+jePrUcQTiOPsoLSfnnSpfUvuSkGEfd7LWgS1RqU 8ddHsevo97H2Cz9qLiUzSvbpbZ7tAknWjzdrBb21S7mjFxyI8/aN07llzCCXOZxqHKuD73v rqosxY5yO1h+hDN8LGRMw== X-UI-Out-Filterresults: notjunk:1;V03:K0:OEZ0b86pTQ4=:dVup1qxlTPoJKVDBUzJYsy BRpHbcK6iFFikhSb+mZ4UEFo+MoN56gpGNxkXNmNiENhiZVBN5JWOpDIiFl8jjkMq36Lc6k79 vzAfW16VrNPR/xR4jKYSkiCchFXBmuy1Dsty0SC32bnC/wZBSi1vlCrQdl0NnKyHLql1Z5kt5 NibV2R1wFmcqixuUL8XMGluSKGvxJtFdIMH3w6w79So5aabtKd6m8p0INcL6RrGj+pcszUm7p TVa0bB2g0+6iv29GXNuM0KUToUm01ktMdCX382dFcPzRFSeFlrDtkqL9rgN5hrVNF6eM8tjF5 2888G5OVKu6E2x5TLFrL6jV52NllOnXwMCtscXmflfRqc3OY5RhMJE4XKcMcKZZf63+aonAAK ttMlTAr15CviHtd+vQpWJzRX08DdkBH6h4bURN7ms6Whw602mh6ZFMZ0sDVM/NSxLf8RiyQiu ExImxv2+RZW4Kw3IbNFFqb96mDO9/2siTn/IFnH7/mV386Evii14bQD/QYUIVFN1LBgQeVgMC RPuznKclDlM3wvuEIIPVo7DUpykLykzKh12fIE3QxJjK/vhzn0y04dZD+OeyiAYVlUXB0w3fs dgsxD0/Wvq05UMkfkhBS0tTg8jJQGe04a1H+JxB8XHRnow0H3fAkeSU6ZxP1UXayQyk/HPx3k y/1X6p9F0LCnJB3WydnXcyjEADleYPQ6PF2zA06OhBGDqO0KqsGdW+0HFKvHxnaJyBmI07XuU ry82M2omo3GlhcjrUjA2rEHLEK+D+EfEzYKd41vkNQ9JmbSKq1xKNoCVjJirGhPLntUHnOwuB 7K9/g6GbiTyz/nXAQfk2K75cySdOgUYOoCvac2bdMg3jo92qE2LWEjM23EizU2QuiXIFKUmxG vpi6k/aPvJF/0VaeLzBKtYeZp0h9PSvpMUGRdZ/DccDD+z9TVj87HDLR1OQgeT0V15FnpS2MO GjoaXs6SmyEgTccruMe5uqfwli8Y3Tf57ROae84Y6Pb/CLFJZ0YRtUQtRIOC0LQ1Yr5nFpWGP foCfOLkpiEls2Wby/v94vFFqXrCPtaZZBHar6QDxU/5I1qBVZnYlBFsto0LcJhq0UURa0jN6U Yt/eZW3QhOymDI= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] building statically linked DSOs with musl On Mon, Jan 03, 2022 at 09:37:00AM +0800, Sebastien Bourdeauducq wrote: > On 1/1/22 20:56, Joakim Sindholt wrote: > > Musl will set up its own internal global libc structure > > with a bunch of values during the initial dynamic loading phase; among > > the members is libc.auxv, which is what __vdsosym will look through wh= en > > trying to find the VDSO. Since you never ran musl's dynamic linker (an= d > > even if your host binary was musl-based, not the one that would have > > initialized the libc.auxv baked in to your statically linked DSO) it > > won't have set up this and a whole host of other things. > > Thanks for the hint. > > libc.auxv seems to be set up by __dls2b, which itself is called by __dls= 2 > via find_sym(&ldso, "__dls2b", 0). > How does this code work when a program is statically linked against musl= ? > It doesn't. This code only runs in the dynamic linking case. In the static linking one, the program is linked against crt0.c, which contains _start and _start_c, which will call __libc_start_main, which itself will call __init_libc. Note that you cannot call __init_libc, because for that you need the original stack pointer, which you don't have. Ciao, Markus