Re: port-mips/59064 (jemalloc switch to 5.3 broke userland)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 13 Apr 2025 12:42:29 +0000
> From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
> 
> > Date: Sun, 13 Apr 2025 13:39:54 +0900
> > From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
> > 
> > I forgot to mention, but userland works even with "initial-exec"
> > TLS model on QEMU and GXemul for mips somehow. Emulation may be
> > not precise enough, or our TLS handling relays on some undefined
> > H/W behaviors?
> 
> Is this for emulating the  RDHWR $3,$29  instruction, 0x7c03e83b?
> 
> There's a funny comment in sys/arch/mips/include/lwp_private.h (which
> was originally added by matt@ to sys/arch/mips/include/mcontext.h
> rev. 1.21 back in 2015):
> 
>      57 		// For some reason the syscall is much faster than
>      58 		// emulating rdhwr $3,$29 on a CN50xx
> 
> https://nxr.NetBSD.org/xref/src/sys/arch/mips/include/lwp_private.h?r=1.1#57
> 
> I wonder if that's related -- gcc emits the RDHWR instruction itself,
> rather than going through the __lwp_gettcb_fast function.

The commit message on sys/arch/mips/include/mcontext.h rev. 1.21 is
even more interesting:

   user:        matt <matt%NetBSD.org@localhost>
   date:        Tue May 26 02:16:38 2015 +0000
   files:       sys/arch/mips/include/mcontext.h
   description:
   Change _lwp_getprivate_fast to use a syscall instead of rdhwr since rdhwr
   emulation is problematic for the CN50xx.

But, of course, this only affects logic that calls __lwp_gettcb_fast
like ld.elf_so -- it doesn't affect code generated by gcc.

If all the libc/tls and ld.elf_so tests are passing (other than
t_rtld_r_debug), that may mean we don't have enough coverage of the
RDHWR path generated by gcc.