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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-mips/59064; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
Cc: Martin Husemann <martin%duskware.de@localhost>, gnats-bugs%netbsd.org@localhost,
	port-mips-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: Re: port-mips/59064 (jemalloc switch to 5.3 broke userland)
Date: Sun, 13 Apr 2025 13:28:49 +0000

 > Date: Sun, 13 Apr 2025 12:42:29 +0000
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 >=20
 > > Date: Sun, 13 Apr 2025 13:39:54 +0900
 > > From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
 > >=20
 > > 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?
 >=20
 > Is this for emulating the  RDHWR $3,$29  instruction, 0x7c03e83b?
 >=20
 > 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):
 >=20
 >      57 		// For some reason the syscall is much faster than
 >      58 		// emulating rdhwr $3,$29 on a CN50xx
 >=20
 > https://nxr.NetBSD.org/xref/src/sys/arch/mips/include/lwp_private.h?r=3D1=
 .1#57
 >=20
 > 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.