21.05 toolchain C tls variables compilation problem
Alexander Tormasov
a.tormasov at innopolis.ru
Thu Jun 10 13:25:06 CEST 2021
Hello Christian,
>
> On Wed, Jun 09, 2021 at 16:45:17 CEST, Alexander Tormasov via users wrote:
>> found that key problem here is
>>> __thread G *g __asm__("" "runtime.g»);
>> in form of
>>> __thread G *g ;
>> it works, so, question - how to use this asm synonym for __thread variables in 10.3?
> Do you also see this error with a Linux-native GCC 10 tool chain?
No, I checked both 9 and 10
they generate something like
.file "t.c"
.text
.globl runtime.g
.section .tbss,"awT", at nobits
.align 8
.type runtime.g, @object
.size runtime.g, 8
runtime.g:
.zero 8
.text
.globl runtime_g
.type runtime_g, @function
runtime_g:
.LFB0:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movq %fs:runtime.g at tpoff, %rax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size runtime_g, .-runtime_g
…
While genode build toolchain generate wrong asm, see previous letter - instead of
movq %fs:runtime.g at tpoff, %rax
it generate syntactically incorrect name for runtime.g
> movl $__emutls_v.*runtime.g, %edi
> call __emutls_get_address
seems that this is genode - build specific problem...
>
> BTW, may the GCC community (or even Stackoverflow) be a much better
> place to ask this general question than this mailing list? I doubt we
> have to offer many GCC experts in the Genode crowd.
may be -while, as you see, this is not gcc bug.
And I hope that you already encounter something like this before, during port to 10.3 of current code base
Sincerely,
Alexander
More information about the users
mailing list