LoongArch vs. __pthread_rwlock_unlock

[Florian Weimer]

* Xi Ruoyao:

> Hi,
>
> In pthread_rwlock_unlock.c we have:
>
> #if OTHER_SHLIB_COMPAT (libpthread, GLIBC_2_2, GLIBC_2_34)
> compat_symbol (libpthread, ___pthread_rwlock_unlock, __pthread_rwlock_unlock,
>            GLIBC_2_2);
> #endif
>
> IIUC it means on ports merged into Glibc after the 2.34 development
> cycle, like LoongArch, __pthread_rwlock_unlock shouldn't be exported
> from libc.so.6 at all.
>
> But unfortunately, for some strange reason I don't know yet, the
> LoongArch libc.so.6 built from Glibc 2.42 and all previous versions
> actually exported this symbol, and it's even listed in
> sysdeps/unix/sysv/linux/loongarch/lp64/libc.abilist.

It's possible that it's because of:

strong_alias (___pthread_rwlock_unlock, __pthread_rwlock_unlock)

And the unconditional exports in nptl/Versions.

Do you see this for other __pthread_rwlock_* symbols?

> The symbol is only actually gone since the commit:
>
> commit 3b2b88cceeb79f73a72367800d91599e2af4bb39 (HEAD)
> Author: Cupertino Miranda <cupertino.miranda@oracle.com>
> Date:   Fri Aug 22 11:37:00 2025 +0100
>
>     elf: early conversion of elf p_flags to mprotect flags
>     
>     This patch replaces _dl_stack_flags global variable by
>     _dl_stack_prot_flags.
>     The advantage is that any convertion from p_flags to final used mprotect
>     flags occurs at loading of p_flags. It avoids repeated spurious
>     convertions of _dl_stack_flags, for example in allocate_thread_stack.
>     
>     This modification was suggested in:
>       https://sourceware.org/pipermail/libc-alpha/2025-March/165537.html
>     
>     Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
>
> But to me it's completely unrelated to __pthread_rwlock_unlock, and we
> are just being (un)lucky here.

That's really odd.  Please figure out what is going on there.

Thanks,
Florian