[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-bugs
Subject:    [Bug libgomp/91938] New: libgomp (and libitm) DSOs are incorrectly built with initial-exec tls-model
From:       "nsz at gcc dot gnu.org" <gcc-bugzilla () gcc ! gnu ! org>
Date:       2019-09-30 15:42:29
Message-ID: bug-91938-4 () http ! gcc ! gnu ! org/bugzilla/
[Download RAW message or body]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91938

            Bug ID: 91938
           Summary: libgomp (and libitm) DSOs are incorrectly built with
                    initial-exec tls-model
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nsz at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

initial-exec tls is only valid in a dso if there is a guarantee
that the dso is never dynamically loaded or the c runtime has
tls reserved specifically for that dso to use.

gcc target libs don't provide such guarantee nor glibc has special
tls for libgomp or libitm so they are broken on *-linux*.

optimizing tls access is only acceptable if it does not break
correctness. (side note: initial-exec tls is required on glibc for
as-safe tls access, if that's necessary then the fix will need
glibc discussions, but the default should be safe for other libcs.)

this hits targets like aarch64 and powerpc* harder where glibc
can optimize dynamic tls in dsos to use the preallocated static
tls area if available so it runs out faster than on targets where
no such optimization is done. (initial-exec tls usage is actually
less performance relevant on those targets for the same reason.)

in principle that glibc logic can be changed to be more consistent
across targets, but i would only support that if there is a way to
coordinate the use of preallocated tls otherwise it's unsupportable.

see the libc-apha discussion
https://sourceware.org/ml/libc-alpha/2019-09/msg00512.html=
[prev in list] [next in list] [prev in thread] [next in thread]