LoongArch vs. __pthread_rwlock_unlock

[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.

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.

So what is the root cause of the unintentional existence of this symbol?
And how should we tackle this issue now?

-- 
Xi Ruoyao <xry111@xry111.site>