|
Message-ID: <6dbcae4a-93f4-f01e-dcde-34b926c4c635@ispras.ru> Date: Sat, 23 Nov 2024 15:36:06 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: Alex Rønne Petersen <alex@...xrp.com> cc: musl@...ts.openwall.com Subject: Re: [PATCH] s390x: Mark __tls_get_addr hidden before invoking it. On Sat, 23 Nov 2024, Alex Rønne Petersen wrote: > 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. I see, thanks. Your commit message was confusing to me, because unlike __syscall_ret and the like, __tls_get_addr is not an internal helper, it may not have hidden visibility anywhere except s390. So it felt like the commit message was drawing a false parallel. I would love this to land with a clearer commit message, but that's up to Rich and yourself to sort out. Alexander
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.