|
Message-ID: <20241213111843.GT10433@brightrain.aerifal.cx> Date: Fri, 13 Dec 2024 06:18:44 -0500 From: Rich Felker <dalias@...c.org> To: Alex Rønne Petersen <alex@...xrp.com> Cc: Fangrui Song <i@...kray.me>, musl@...ts.openwall.com, Alexander Monakov <amonakov@...ras.ru> Subject: Re: [PATCH] s390x: Mark __tls_get_addr hidden before invoking it. On Thu, Dec 12, 2024 at 06:45:39PM +0100, Alex Rønne Petersen wrote: > On Sat, Nov 30, 2024 at 6:51 PM Fangrui Song <i@...kray.me> wrote: > > (I am not versed in s390x assembly, but I have some notes about __tls_get_offset > > > > https://maskray.me/blog/2024-02-11-toolchain-notes-on-z-architecture#general-dynamic-tls-model > > > > The 32-bit ABI had to use __tls_get_offset because some nice > > general-instructions-extension was unavailable when the ABI was > > codified. > > The 64-bit ABI following the 32-bit __tls_get_offset was just unfortunate.. > > From your notes, it sounds like __tls_get_addr has to be hidden, even > if we don't actually make use of it in __tls_get_offset. Is my > understanding correct? > > If yes, what would be the preferred way to achieve this in musl? There is no requirement for a symbol to be hidden unless it violates namespace, which is not the case here. The problem is that the code in __tls_get_offset is performing a call to __tls_get_addr in a manner that's not valid unless the call target is local. My preferred fix would be getting rid of the call and inlining __tls_get_addr into __tls_get_offset. This was not possible back when the port was added because __tls_get_addr had a complex code path for installing new TLS on first-access. That was changed long ago, so now it's a fairly trivial instruction sequence. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.