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: 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: Sat, 12 Apr 2025 13:55:51 +0000

 > Date: Sat, 12 Apr 2025 18:38:08 +0900
 > From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
 >  
 > I've carried out bisectioning for upstream repo to find out
 > the first bad commit:
 > 
 > https://github.com/jemalloc/jemalloc/commit/1aabab5f
 > 
 > By reverting this commit from our in-tree jemalloc, both n64 and
 > n32 userlands successfully boot up into multi-user mode on ERLite-3.
 > 
 > However, now, statically-linked binaries crash via:
 > abort() <-- __tls_get_addr() <-- malloc_init_hard() <-- _initarray()
 > 
 > This can be a hint for what going on with and without the
 > commit in problem.
 
 Can you run the libc tls and rtld tests and see if they pass on these
 platforms?
 
 atf-run /usr/tests/lib/libc/tls /usr/tests/libexec/ld.elf-so | atf-report
 
 Do we have any regular test runs of the same architecture/ABI that we
 can consult for past results of the tls and rtld tests?
 
 It's curious that __tls_get_addr calls occur at all.  I don't think
 it's supposed to happen in statically linked binaries, because there
 is only one TLS block, so the linker should eliminate __tls_get_addr
 calls.
 
 How did you produce a statically linked binary that exhibits this
 behaviour?  Can you post the objdump -dlr output for it?