re: __atomic_test_and_set() and mips o32 - help wanted
"Maciej W. Rozycki" <[email protected]> Mon, 24 Nov 2025 18:16:52 +0000 (GMT)
| Newsgroups | gmane.os.netbsd.ports.alpha,gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.devel.toolchain |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 22 Nov 2025, matthew green wrote: > > Hmm, so where does the original issue reported with this thread come > > from? It seems like something that should have been long sorted. > > it comes from GDB calling C++'s "test_and_set()" which in GCC 14's > libstdc++ is implemented as direct calls to __atomic_test_and_set(). > > libgdb.a(minsyms.o): in function `minimal_symbol_reader::install()': > minsyms.c:(.text+0x4224): undefined reference to `__atomic_test_and_set' Ah, I see. I think I got confused by your original description. So I investigated it a little and this is a compiler intrinsic, for which to be available the backend needs to implement one of four alternative RTL machine instructions, in this order of preference: `atomic_test_and_set', `atomic_exchange', `atomic_compare_and_swap' or `sync_lock_test_and_set'. The MIPS backend implements `atomic_exchange' with an LL/SC loop or, for the XLP CPU (that was an interesting one!), with the SWAP instruction. It also implements `atomic_compare_and_swap' and `sync_lock_test_and_set', with LL/SC. There's no fallback to a libcall implemented AFAICT, hence the link failure, and the API would have to be provided by libatomic. I can only see code for an ARM target there. A couple more atomic functions might be good having provided then beyond `__atomic_test_and_set' for better code generation in the absence of LL/SC (be it real or emulated). Maciej