[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH9TF6M6qsUU=OB41xYtkAe37WuQp=0n_reLZM2aSmiRDCEf6g@mail.gmail.com>
Date: Sat, 23 Nov 2024 13:15:07 +0100
From: Alex Rønne Petersen <alex@...xrp.com>
To: Alexander Monakov <amonakov@...ras.ru>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] s390x: Mark __tls_get_addr hidden before invoking it.
On Sat, Nov 23, 2024 at 9:30 AM Alexander Monakov <amonakov@...ras.ru> wrote:
>
> On Sat, 23 Nov 2024, Alex Rønne Petersen wrote:
>
> > Similar to what's done for __syscall_ret, __sigsetjmp_tail, etc. This fixes a
> > linker error when building musl libc.so with zig cc.
>
> Hm, on s390 __tls_get_addr is not used for TLS ABI, so it's fine that it ends up
> hidden in libc.so. Unusual.
>
> (linkers must take the most restrictive visibility from all mentions of a symbol)
>
> I'm curious, what kind of error with zig cc were you seeing?
This:
ld.lld: error: relocation R_390_PC32DBL cannot be used against symbol
'__tls_get_addr'; recompile with -fPIC
>>> defined in obj/src/thread/__tls_get_addr.lo
>>> referenced by __tls_get_offset.s:8 (src/thread/s390x/__tls_get_offset.s:8)
>>> obj/src/thread/s390x/__tls_get_offset.lo:(.text+0x10)
(-fPIC is actually in use.)
Presumably this could be fixed in lld, considering GNU ld seems fine
with it. But I figured that, since glibc also marks __tls_get_addr
hidden for s390x, musl should probably just do the same anyway.
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.
