From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 61D123146B for ; Tue, 17 Dec 2024 17:26:15 +0100 (CET) Received: (qmail 30444 invoked by uid 550); 17 Dec 2024 16:25:48 -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 x-ms-reactions: disallow Received: (qmail 30389 invoked from network); 17 Dec 2024 16:25:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1734452739; x=1735057539; i=nullplan@gmx.net; bh=yl9WA5rfjMuIlgxPgRzpo9af+0Vw2paLeGoGyS8KOjM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=d8YLnPeFTVZb5WF8Ebn3hX5nyuTFGqnA7jr8j4TqqkTIxQL01RXZfFZDk6mgljhu I74oygjqfWDfkADay30Fi9LaFCrVl6B4KgVYU9pHMRV1GmkVdBwWLHCes23OpE86b u/cszhu7VhZYZoLDxuysIhNrg55jsnhwZQ7XJCu8OMIlmeUKl14hRmPEKhQEcgxQC vPIbq9m91M0nt5n4wzGKG9pzCOjR9kydYeYWqk2QKwN0/cX71Hs6dujXX5PQ3BLz3 Y92TbTblrMLFF90YaeF2Pvx1wlGPGxIJ0vNRVAHEqKOE/qLb/ApGR/vwdCjzWik9e L0Lk0h3Z1bzcIf9hLA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Tue, 17 Dec 2024 17:25:37 +0100 From: Markus Wichmann To: musl@lists.openwall.com Cc: " ." Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:8ei0m3bhr8t/XQI/whTsfM4lDBv0qY1hLGswq/lIUwwGsUysVWA p7j5Gng5h6I8MgCidRMGP3unOz0kYmWE2oAWQWtzpuHOpgG46vKdVXCYAoWIqkPGNs8eXc3 +jzqdQ+DZe/RdKaAEnlnGW60x8PGnLaHCUDjpD8sq87ZEm3kUMh8bhKa5JQ7USsM0fnKtzI lzXnnr6cMaVUQljv9aotg== UI-OutboundReport: notjunk:1;M01:P0:mnwf3+YIM78=;7+5J3Lyot/mu7zBPScRlnQfWnxG 0fNhtSQdvSRUhyPxWYmxNoWvQ1zdTOhYhGKsEFFDRx/A7xTiZUgS1YIOGc28ta4mfbQqRTJwa pJVfjDD638NTCM2tg09r554uj88vAbYdpVw8eLLOJvtRNGiQwLNRvYRRhT/HZSm2fGha8vOkF ubyI+gCgO5v0fjt7VqkQ6TWE3SI5ve60moU4it8RgGtItep3Kz0nHVf+Rs2+kYzZJq5nJ+BIl IeMm+4CiMCBRKHPSViFsGZX0cRqNEm+msPerHWvcb/dHgqJ6mZP3FJv4qtmkZERymwlT+pCba QMgkyBfKIAu+hXZRlPDiPPYTkk3l9tHQUsPVNErbfFBbfU34OrhYn1AGIz2kl6f9b0/vH0F8J PkkNscoSVPY9zNJamNhTQjn1YJA2Rt+kkEiw8OHZ5CPEU9ZhO2DzIYBLyLWTR5HCRB+CEqVcG NSV5fzdWKj3Bv1Wj+JALT7kzFz2fkX2kber3xRiZ0RsjlKy8YBo+ZZ4PcV8im1/DomyrA3ygn jdMtUMirn8j8mx6FtcWoNBup+vfaHsnopjhBi7ZzHFaRX4zneKlaIRwP6qVcXLmppGEEZIoxe g0QvaFdpGENDTkZ7FvKGaB3ZfDTJ6+mdQTq4/vNaMt/66M3gyu8+brhAvb1mwWrUIDhgMm5Mc eiLAw+jX3LE6DUv2BvP+WAFoixxhx2Bhv9eAxHhH+kbMuQ898XMLRXTEJKI7BjmRwl7X8meOy rU7geclwpTyFZOy58XtTNhk1yFr0fbTAp3sScCetliyMlz2HuEJvr1l3rIvYZIzqfroGN1umY eHhn9Yn1BBdZkjJ97wpu7pwituqdInnPgCZoWpnBsjobXYA4lGkd5KGkD7ez1RGDmhN/SNGR3 sp2Fv89sa9rAmbfRtqVAevvia8RHmxmU/YvRpSnPQkyhaQuvmyZx4xSYgc5bD0/9PWNXJQDWZ iAQqvNRqBVQtsOVDKlrzm7sI14aydpT3e0G2jj5abqj9qOqZxt/y87qaLJk2nB1JGHoOvmj4P osJAMH4kAQUezwakdUJRb9QiZERjMvDm+LCgMjlH7OkSNnF/mSVsUkG6x2FmPbC9TwjrNy5pa y/QmYdIU+Scm9C9x3Zf4B4ao3937n6 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Question about the TLS Am Tue, Dec 17, 2024 at 03:11:06PM +0800 schrieb .: > Hi > I have one question in TLS. > I intend to incorporate a Thread-Local Storage (TLS) variable into the m= usl library.  However, the musl library does not currently support th= e  > handling of TLS variables within the ldso library.  Could you pleas= e advise if there are any potential risks or issues associated with adding= TLS >  variables and the corresponding processing logic? > Best > ye > >   Main problem that I see is the bootstrapping of TLS relocations inside of LDSO at this time. LDSO bootstrapping at this point works like this: - Stage 1 (dlstart.c): Process relative ldso relocations. - Stage 2: - Initialize dynamic linking structures - Temporarily process symbolic ldso relocations - Stage 2b: Set thread pointer to builtin TLS initially. - Stage 3: - Load LD_PRELOAD + possibly app + dependencies - Process all relocations (including symbolic ldso relocs again) - Properly initialize TLS and thread pointer. The initialization of TLS requires that the allocator (malloc et al.) work already. This requires that all dependencies be loaded and symbolic relocations be done. At this point, the only way I can think of to do this would be to create a stage 4 for all the TLS stuff. You'd have to shuffle some code around, and ensure that stage 3 never calls any stuff that depends on TLS until it is set up in stage 4. What do you want TLS in libc for, anyway? Mayhaps a simpler thing would be to add a field to struct __pthread? Ciao, Markus