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