SIGSEGV in TLS startup on mips/musl with rcrt1.o

[aep]

this looks like a bug in musl's rcrt1.o to me, but i can't quite give the musl guys any useful information here

Program received signal SIGSEGV, Segmentation fault.
0x77fbfb1c in core::cell::Cell<bool>::get<bool> () at /checkout/src/libcore/cell.rs:240
240	/checkout/src/libcore/cell.rs: No such file or directory.
(gdb) bt
#0  0x77fbfb1c in core::cell::Cell<bool>::get<bool> () at /checkout/src/libcore/cell.rs:240
#1  std::thread::local::fast::Key<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>>::get<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>> () at /checkout/src/libstd/thread/local.rs:421
#2  std::sys_common::thread_info::THREAD_INFO::__getit () at /checkout/src/libstd/thread/local.rs:184
#3  std::thread::local::LocalKey<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>>::try_with<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>,closure,()> () at /checkout/src/libstd/thread/local.rs:376
#4  std::thread::local::LocalKey<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>>::with<core::cell::RefCell<core::option::Option<std::sys_common::thread_info::ThreadInfo>>,closure,()> () at /checkout/src/libstd/thread/local.rs:293
#5  std::sys_common::thread_info::set () at /checkout/src/libstd/sys_common/thread_info.rs:46
#6  0x77fc3350 in std::rt::lang_start () at /checkout/src/libstd/rt.rs:52
#7  0x77fb1408 in main ()

this only happens when using rcrt1.o as entrypoint, not with Scrt1.o , so i suspect something related to TLS must be different in rcrt1

I'd appecheciate some pointers from the rust community here how TLS is different than for C++ so i can show a better test case to musl.

[richfelker]

Can you clarify what you mean by "happens with rcrt1.o but not with Scrt1.o"? They are not interchangible. rcrt1.o is valid only with static pie (no PT_INTERP) and Scrt1.o is valid for dynamic pie (ET_DYN + PT_INTERP) or for ET_EXEC (but not normally used for the latter). I believe rcrt1.o's limited relocation handling means it only works when TLS accesses have been generated (by the compiler) or relaxed (by the linker) for local-exec model; dynamic models might not work. If needed adding support for them should be possible.

[aep]

indeed

• does happen for ET_DYN with no PT_INTERP and rcrt1
• does not happen with ET_DYN+PT_INTERP set to /lib/ld-musl-mips-sf.so.1 with Scrt1

from my experience implementing bolter, rust uses all 4 TLS models and somtimes they can't be relaxed, so this could be the problem. Unfortunately i have no idea how to read relocations out of a mips binary to confirm

[richfelker]

OK, that's probably the cause then. Can you show me a simple object file with TLS where access fails?

[aep]

@richfelker this is a simple hello world that crashes as described

hello.zip

but if i read the output of readelf correctly, the only tls reloc is R_MIPS_TLS_DTPMOD

[richfelker]

Let me know if this patch helps:

rcrt_diff.txt

[aep]

@richfelker yes, this fixes it! thank you so much. This will allow fully statically linked PIE binaries in rust. weeee

[richfelker]

Thinking about it more, for non-pie static linking, there is no runtime relocation at all, so the linker must know how to perform the DTPMOD relocation at ld time (i.e. fill in the 1). In fact bfd ld elfxx-mips.c's mips_elf_initialize_tls_slots function knows how to do this, but fails to do it in the pie case because of a logic bug I just reported:

https://sourceware.org/bugzilla/show_bug.cgi?id=22570

Most other archs are not affected because they have TLS relaxations that convert the dynamic models to initial/local exec models at ld time, but mips seems to lack relaxations.

Feel free to use the musl rcrt1 patch for now if you like, but I don't think it's the right fix. This is not something rcrt1 should need to do.

[richfelker]

Can you please reopen the issue until the correct course of action for resolving it upstream (in binutils and/or in musl) is determined?

[steveklabnik]

It's been over a year; does anyone know what the next steps should be?

[aep]

we completely pulled rust from all projects, so i cant test this.
But i believe this is fixed in gnu ld.
Since we're the only ones who used to do rust on low spec hardware we might just close this.