Changes to buildtools results in libstdc++ with broken TLS support

[jessicah]

As a result of merging patches in #12430, which changed when the -shared flag gets passed onto ld, has broken Haiku's TLS support when building gcc4/libstdc++ on Haiku.

As a result of the changes, gcc generates R_386_TLS_TPOFF32 relocations in the configure test for TLS, instead of previously R_386_TLS_DTPMOD32 & R_386_TLS_DTPOFF32. Currently, runtime_loader doesn't support R_386_TLS_TPOFF32 relocations. Due to the failed test, libstdc++.so is generated with different symbols (e.g. no std::__once_call), which breaks apps that use TLS (WebPositive being one).

Example test:

__thread int a;
int b;
int main() {
  return a = b;
}

My only change to gcc/config/i386/haiku.h: s/%{shared:-shared;/%{!r:-shared;/ which was enough to make TLS support work again, but obviously isn't ideal.

It looks like we have two options: continue to pass -shared onto the linker in the LINK_SPECS, or to improve TLS support in runtime_loader.

[jessicah]

Example of binary with unsupported TLS relocations

[jessicah]

If you need updated packages of gcc/binutils, they can be found at ​http://haiku.jessicah.org/packages.

[axeld]

I've granted simonsouth developer access on Trac, and assigned this ticket to him.

[simonsouth]

Thanks, Axel, and thank you very much for the packages, Jessica.

Naturally I believe the solution here is to improve runtime_loader. I'm looking into this now.

[jessicah]

It's not just changes to runtime_loader that will be needed. I was also told that part of our TLS implementation lives in kernel land, and that it would likely need to be moved into runtime_loader. See ​https://github.com/haiku/haiku/blob/master/src/system/libroot/os/arch/x86_64/tls.cpp#L75 for reference.

From ​http://www.airs.com/blog/archives/44 the two variants of TLS we don't support are "Initial Executable' and 'Local Executable'. Previously, when everything was linked as shared, obviously these two TLS cases were not applicable, hence didn't need implementation ;-)

[jessicah]

Also, some other places to look for the current TLS implementation:

• ​https://github.com/haiku/haiku/blob/master/src/system/kernel/thread.cpp
• ​https://github.com/haiku/haiku/blob/master/src/system/kernel/arch/x86/arch_thread.cpp#L193
• ​https://github.com/haiku/haiku/blob/master/src/system/kernel/arch/x86/64/thread.cpp#L91

Should help give a little bit more of a head start :-D

[korli]

Should we consider applying the workaround for the time being?

[simonsouth]

We will probably have to do something in the short term, if a way can't be found to disable these optimizations in the linker.

I'm determined to come up with a solution that doesn't involve undoing my changes to gcc but the more I look into the problem, the bigger it seems to get. (I'm still learning how threads and TLS are implemented within Haiku and trying to understand how this can be reconciled with what the ELF ABI defines.)