https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
Bug ID: 103275
Summary: don't generate kmov with IE model relocations
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at zx2c4 dot com
Target Milestone: ---
This is a spin-off from https://sourceware.org/bugzilla/show_bug.cgi?id=28595
1.c:
extern __thread int mytls __attribute__((tls_model ("initial-exec")));
__attribute__((noipa)) void
foo (void)
{
asm ("");
}
int
main ()
{
foo ();
#ifdef KMOVD
asm volatile ("kmovd mytls@gotntpoff(%%ebx), %%k0" : : : "k0");
#else
volatile int a = mytls;
#endif
return 0;
}
2.c:
__thread int mytls __attribute__((tls_model ("initial-exec")));
$ gcc -O2 -m32 -fPIC /tmp/1.c /tmp/2.c -o /tmp/1 -UKMOVD -mavx512f
$ gcc -O2 -m32 -fPIC /tmp/1.c /tmp/2.c -o /tmp/1 -DKMOVD -mavx512f
/usr/bin/ld: /tmp/ccQrvWxU.o: TLS transition from R_386_TLS_GOTIE to
R_386_TLS_LE_32 against `mytls' at 0x1c in section `.text.startup' failed
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
That results from the type check returning false here:
case R_386_TLS_GOTIE:
case R_386_TLS_IE_32:
/* Check transition from {IE_32,GOTIE} access model:
subl foo@{tpoff,gontoff}(%reg1), %reg2
movl foo@{tpoff,gontoff}(%reg1), %reg2
addl foo@{tpoff,gontoff}(%reg1), %reg2
*/
if (offset < 2 || (offset + 4) > sec->size)
return false;
val = bfd_get_8 (abfd, contents + offset - 1);
if ((val & 0xc0) != 0x80 || (val & 7) == 4)
return false;
type = bfd_get_8 (abfd, contents + offset - 2);
return type == 0x8b || type == 0x2b || type == 0x03;
In the ensuing discussion, Florian thought that GAS shouldn't even be
assembling it, because that's not a valid relocation type. As a consequence,
GCC shouldn't be emitting it either, which it is in the context of glibc.
Quoting Jakub:
> https://akkadia.org/drepper/tls.pdf
> I don't remember anymore whether it is ok if some of the TLS
> relocations appear also in instructions not exactly mentioned
> in the above mentioned pdf and if instead of giving the linker
> errors like the above the linker should just not optimize a
> particular TLS model, i.e. still use IE model here when it
> can't optimize it into LE model (then it would be a linker bug),
> or whether the compiler needs to ensure that those @gotntpoff
> etc. appear solely in the instructions mentioned in the pdf
> (here in movl). In that case it would be a gcc bug, e.g. for
> the @gotntpoff MEMs it would need to disallow them by default
> and only accept them as a special case in a simple *movsi_internal.
