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=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20383 invoked from network); 3 Jan 2022 01:37:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2022 01:37:22 -0000 Received: (qmail 12253 invoked by uid 550); 3 Jan 2022 01:37:18 -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 12215 invoked from network); 3 Jan 2022 01:37:18 -0000 Message-ID: <98176a37-92c6-0da5-c14a-f61b4f8b13ec@m-labs.hk> Date: Mon, 3 Jan 2022 09:37:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: musl@lists.openwall.com References: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk> From: Sebastien Bourdeauducq In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] building statically linked DSOs with musl 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 when > trying to find the VDSO. Since you never ran musl's dynamic linker (and > 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 __dls2 via find_sym(&ldso, "__dls2b", 0). How does this code work when a program is statically linked against musl? On 1/3/22 05:41, Markus Wichmann wrote: > There can be different heaps, but not different brk heaps. Basically, > brk() manages a global variable generated by the kernel. You can work > around that problem by installing a seccomp filter that makes brk() > always fail, forcing the allocators to fall back to mmap(). mimalloc exclusively uses mmap() already, so that will be OK and will not require a workaround. It shouldn't matter if the other allocator uses brk(). > The thread pointer does not match up, Seems it does (okay, probably by accident): https://git.musl-libc.org/cgit/musl/tree/arch/x86_64/pthread_arch.h?id=cfdfd5ea3ce14c6abf7fb22a531f3d99518b5a1b#n4 https://github.com/bminor/glibc/blob/b92a49359f33a461db080a33940d73f47c756126/sysdeps/x86/nptl/thread_pointer.h#L30 > and so no functions accessing the thread pointers will work. That > includes functions that read the current thread pointer, so you cannot > know in advance which those are. All the implementation-defined > structures mismatch, so none of the locking functions work, and neither > do the semaphore functions. AFAIK I would not need to share locks or semaphores across the plugin. I need to see if the rest of this thread business has other consequences. Sébastien