[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241222141425.GA10433@brightrain.aerifal.cx>
Date: Sun, 22 Dec 2024 09:14:25 -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 Sun, Dec 22, 2024 at 02:53:33PM +0100, Alex Rønne Petersen wrote:
> On Sun, Dec 22, 2024 at 2:23 PM Rich Felker <dalias@...c.org> wrote:
> >
> > On Fri, Dec 13, 2024 at 08:04:22PM +0100, Alex Rønne Petersen wrote:
> > > On Fri, Dec 13, 2024 at 12:18 PM Rich Felker <dalias@...c.org> wrote:
> > > >
> > > > 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.
> > >
> > > Before I send a patch, just to confirm, is this what you have in mind?
> > >
> > > .global __tls_get_offset
> > > .type __tls_get_offset,%function
> > > __tls_get_offset:
> > > stmg %r14, %r15, 112(%r15)
> > > aghi %r15, -160
> > >
> > > ear %r0, %a0
> > > sllg %r0, %r0, 32
> > > ear %r0, %a1
> > >
> > > la %r1, 0(%r2, %r12)
> > >
> > > lg %r3, 0(%r1)
> > > sllg %r4, %r3, 3
> > > lg %r5, 8(%r0)
> > > lg %r2, 0(%r4, %r5)
> > > ag %r2, 8(%r1)
> > > sgr %r2, %r0
> > >
> > > lmg %r14, %r15, 272(%r15)
> > > br %r14
> >
> > I'm not clear on what you're setting up the stack frame (munging r14
> > and r15) for. My disasm of existing __tls_get_addr doesn't do that,
> > and it doesn't seem to be useful for a leaf function -- or desirable
> > for one that's a critical hot path.
>
> That was already there in the __tls_get_offset asm. I wasn't sure if
> removing it is fine ABI-wise. If it is, then I'll definitely do so.
Must be different gcc version or cflags...
> > The 3 lines before loading the actual argument from r2+r12 also look
> > wrong. I don't understand s390x asm very well but I don't see how they
> > could do anything meaningful there.
>
> %r0 is used twice: Once in the code inlined from __tls_get_addr and
> once more to subtract the thread pointer before return as you mention
> below.
Ahh, that's just loading the thread pointer. I forgot the weird insn
sequence for that. So I think it looks right.
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.
