Closed Bug 1317176 Opened 3 years ago Closed 2 years ago

NSPR for Windows uses static TLS which is not supported by GCC

Categories

(NSPR :: NSPR, defect)

4.12
defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ambrop7, Unassigned)

References

Details

Attachments

(2 files)

Attached patch static-tls.patchSplinter Review
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36

Steps to reproduce:

Tried to cross-compile NSPR from Linux to Windows using GCC. Exact procedure is out of scope, it involves some hacks to the build system. Same issue must exist if native-compiling on Windows with GCC.


Actual results:

Crash in _PR_ClockInterrupt very soon after starting application, or if built with debug, assertion failure within PR_Init (prulock.c:210: PR_ASSERT(!(me->flags & _PR_IDLE_THREAD))). Warnings during compilation about unsupported __declspec(thread).

Attached is patch which resolved this bug. With this patch the errors are resolved.


Expected results:

Code must not use static TLS when compiled with gcc.
(In reply to Ambroz Bizjak from comment #0)
> Warnings during compilation
> about unsupported __declspec(thread).

Doesn't GCC support C++11 thread_local either?
Yes, though that is for C++. But apparently it does have __thread. I've made a slight modification to my patch so it uses __thread with GCC, __declspec(thread) with MSVC, and none otherwise. Seems to work.

Is it okay this way, or should I remove support for no static TLS at all? I think it's fine - it leaves possibilty to use compilers which support none of this, and the macros solve some slight code duplication.
I cross-compile with MinGW regularly and haven't hit this.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
See Also: → 1460645
You need to log in before you can comment on or make changes to this bug.