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

["Rin Okuyama via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>,
 Martin Husemann <martin%duskware.de@localhost>
Cc: 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:39:54 +0900

 On 2025/04/12 23:51, Taylor R Campbell wrote:
 > Can you try the attached patch?  Will require a clean build of
 > anything that uses bsd.lib.mk.  (Will also need something to wash the
 > embarrassment off my face if this turns out to be the culprit!)
 
 Thank you very much for finding it out!
 
 Statically-linked binaries (specifically, /rescue/*) on n{64,32}
 userland on ERLite-3 work just fine on ERLite-3, if "initial-exec"
 attribute is removed at the same time.
 
 Also, libc/tls and ld.elf_so tests becomes working again
 (except for t_rtld_r_debug).
 
 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?
 
 By examining `VMFAULT_TRACE` codes of mips/trap.c, __BIT(40) is
 turned on for fault addresses, e.g., 0x1fff0a25050 (for most cases?).
 This is odd as our user address space is only 40-bit for mips64.
 
 I've not figured out what is going on for ERLite-3...
 
 Thanks,
 rin
 
 PS
 Also, your patch fixes recent ATF regressions for arm:
 
 - lib/libc/tls/t_tls_static:t_tls_static
 - usr.bin/c++/t_cxxruntime:cxxruntime_static
 - usr.bin/c++/t_static_destructor:static_destructor_static
 
 I've just noticed that these tests abort by calling libc stub of
 _tls_get_addr(), in a similar manner to mips.