Opened 3 years ago

Last modified 10 months ago

#12451 assigned bug

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

Reported by: jessicah Owned by: simonsouth
Priority: normal Milestone: Unscheduled
Component: System/runtime_loader Version: R1/Development
Keywords: Cc: simonsouth
Blocked By: Blocking:
Has a Patch: no Platform: All


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, 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.

Attachments (1)

broken-tls-example (5.3 KB) - added by jessicah 3 years ago.
Example of binary with unsupported TLS relocations

Download all attachments as: .zip

Change History (9)

Changed 3 years ago by jessicah

Attachment: broken-tls-example added

Example of binary with unsupported TLS relocations

comment:1 Changed 3 years ago by jessicah

If you need updated packages of gcc/binutils, they can be found at

comment:2 Changed 3 years ago by bonefish

Owner: changed from bonefish to nobody
Status: newassigned

comment:3 Changed 3 years ago by axeld

Owner: changed from nobody to simonsouth

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

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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 for reference.

From 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 ;-)

comment:7 Changed 3 years ago by korli

Should we consider applying the workaround for the time being?

comment:8 Changed 3 years ago by 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.)

Note: See TracTickets for help on using tickets.