This should be in a working state if anyone wants to help test. I've tested it working on all three (GCC4.7, GCC9, GCC12) toolchains. While I can't test on NAOMI (yet) I believe the changes to the linker script are pretty sane and copy/pasted from the tested Dreamcast one and should work.

Ensured Newlib's C and C++ stdlibs are now using TLS gracefully for reentrancy

I think any Newlib changes should be investigated in a future PR instead of this one, as Newlib support for TLS replacing the reent struct is relatively new. It was added in this commit, and would only be possible with the GCC12 toolchain.

Ensured Newlib's C and C++ stdlibs are now using TLS gracefully for reentrancy

I think any Newlib changes should be investigated in a future PR instead of this one, as Newlib support for TLS replacing the reent struct is relatively new. It was added in this commit, and would only be possible with the GCC12 toolchain.

Yeah, after talking to you, I agree. Updated the main comment to remove that but also added the diligent toolchain testing you've done too. When I get a chance, I'll help do some testing on the C++ side.

If anyone has anything they'd like to add or see, this PR is basically ready other than a bit more testing, which I'm holding off on until I finish writing a bunch of unit tests for libGimbal's concurrency stuff, which is about to flex this all pretty hard!

Just wanted to leave an update for myself and anyone else following along, because I'm about to have a big move and will be changing jobs, and have been investigating/testing this quite a bit to continue our sacred quest for TLS support.

I've been really diligent about testing and researching good test scenarios for TLS with libGimbal and have managed to break our initial implementation in two different ways:

• TLS accesses for the main thread are incorrect
• TLS accesses for manually overaligned values are incorrect

I'm not quite sure what's causing the former, but I'm fairly certain it's probably something trivial and dumb (are we not setting GBR for the main thread)? The latter issue; however, is going to be quite a bit more in-depth...

Luckily it looks like supporting odd alignments in TLS is a common issue that is run into in other indie/retro SDKs, and I've actually managed to find a really good reference implementation for addressing the same issue in the Nintendo 3DS DevkitPro SDK: devkitPro/libctru#497 (thank you from the Dreamcast scene, my dudes). We can most likely follow along with these breadcrumbs and implement this fix similarly, ensuring proper alignment for the TLS fields of the whole outer thread struct.

Anyway, I'll be back to working on this ASAP, because I need it for my own engine and concurrency model. Just wanted to leave these notes for myself and anyone else in the meantime.

EDIT: For reproducing/troubleshooting these two issues, the little TLS example can be modified to also use the counter on the main thread, which will immediately return/print the wrong value.

Then in my own libGimbal tests, I was flexing random alignments with the following, which were winding up all kinds of screwed up:

static _Thread_local              uint16_t      tlsUint16_      = '\0';
static _Thread_local _Alignas(16) int32_t       tlsInt32_       = -346;
static _Thread_local              GblStringRef* tlsStringRef_   = NULL;
static _Thread_local _Alignas(32) char          tlsCharArray_[] = { "abcdefghijklmnopqrstuvwxyz012345" };
static _Thread_local _Alignas(64) GblObject     tlsObject_;
static _Thread_local _Alignas(8)  double        tlsDouble_      = 12345.6789;

My WIP unit tests for flexing this are located here: https://github.com/gyrovorbis/libgimbal/blob/master/test/source/core/gimbal_thread_test_suite.c

I have fantastic news to report on the quest for TLS... I CANNOT REPRODUCE THE PROBLEMS I FOUND ON GCC13! I'm not sure what the heck is going on or if 12 had issues or what the deal was, but I've modified your example to flex the two things I was mentioning 1) main thread using TLS data 2) weirdly aligned TLS data, and it all works fine.

I am, however, still facing one last issue with my libGimbal codebase using TLS... Every time I try to link to a statically linked library that uses TLS variables that get referenced from the main program, the compiler emits __emu_tls_() symbols, which seem to totally break the code in the final binary... I'm trying to play with toolchain configurations and global build flags (stuff like -fno-pic and -fno-pie) to see if I can get it to always emit GBR offset accesses to TLS variables.

Btw, is there any way you can give me permission to push back to this branch? I can add my changes to your example flexing the other two issues so you can verify they're working for you too.

I was able to replicate the issue with using TLS on the main thread. I just wasn't setting the GBR register for the main thread so it was not accessing the correct memory region when attempting to access TLS variables. This was only an issue for the main thread as it's the only thread that sets up its own thread structure, all others will have the GBR loaded during a context switch.

It has been a long long long time coming, but we got TLS working!!!

It has been validated with both the new compiler_tls example from Colton and my MASSIVE libGimbal unit test suite. Here's the threading tests I put KOS through that all passed:
https://github.com/gyrovorbis/libgimbal/blob/master/test/source/core/gimbal_thread_test_suite.c

Between the two, I feel like we've thrown everything at the TLS implementation that I can think of... she's finally ready! Really excited about this one!

Review feedback addressed, rebuilt KOS along with the example and nothing has broken (thank god). :)