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

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

> 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?