Use -ftls-model=local-exec for RTEMS by default?
Hello, RTEMS applications are usually fully statically linked together with the operating system. So, we can use the -ftls-model=local-exec TLS model. The default value for this option is defined in common.opt: ftls-model= Common Joined RejectNegative Enum(tls_model) Var(flag_tls_default) Init(TLS_MODEL_GLOBAL_DYNAMIC) -ftls-model=[global-dynamic|local-dynamic|initial-exec|local-exec] Set the default thread-local storage code generation model. Would it be possible to customize the default value for RTEMS? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] powerpc: add documentation for HWCAPs
Excerpts from Tulio Magno Quites Machado Filho's message of July 16, 2022 6:17 am: > Segher Boessenkool writes: > >> That is a usability problem. Can it be fixed, or will that create its >> own compatibility problems? In practice I mean. If it is, the C >> libraries could fix it up, for new programs, and then after a while the >> kernel can do the sane thing? >> >> How big is the problem, anyway? Is it only 2.05, or also 2.04, 2.03? > > PPC_FEATURE_ARCH_2_05 is the first bit referring to an ISA level. > Before that, AT_HWCAP used to have bits for specific processors, e.g. > PPC_FEATURE_CELL and PPC_FEATURE_POWER4. > > Notice that glibc creates its own hwcap-based information that is used by > __builtin_cpu_supports(). In this case bits PPC_FEATURE_ARCH_2_05, > PPC_FEATURE_POWER5_PLUS, PPC_FEATURE_POWER5 and PPC_FEATURE_POWER4 are enabled > whenever if the processor is compatible with the features provided by any of > the previous processors [1]. > AT_HWCAP and AT_HWCAP2 are kept intact, though. > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/hwcapinfo.c;h=afde05f86382413ce1f0c38e33c9bdd38d6b7e9d;hb=HEAD#l45 Hmm, this doesn't seem very nice. That said, before possibly changing that in the kernel, documenting existing unexpected behaviour is probably a good idea. Good catch, I obviously wasn't careful enough reviewing these bits. I'll send out a final patch with this adjustment in a week or so in case any more comments come in the meantime. Thanks, Nick
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20/07/2022 10:43, Sebastian Huber wrote:
Hello,
RTEMS applications are usually fully statically linked together with the
operating system. So, we can use the -ftls-model=local-exec TLS model.
The default value for this option is defined in common.opt:
ftls-model=
Common Joined RejectNegative Enum(tls_model) Var(flag_tls_default)
Init(TLS_MODEL_GLOBAL_DYNAMIC)
-ftls-model=[global-dynamic|local-dynamic|initial-exec|local-exec]
Set the default thread-local storage code generation model.
Would it be possible to customize the default value for RTEMS?
I think this could be done by adding
#define CC1_SPEC "%{!ftls-model=*:-ftls-model=local-exec}"
to gcc/config/rtems.h. However, the CC1_SPEC is also defined by several
targets. Would it be possible to add an OS_CC1_SPEC like this?
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index bb07cc244e3..7ddabc888b0 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -709,6 +709,12 @@ proper position among the other output files. */
#define CC1_SPEC ""
#endif
+/* config.h can define OS_CC1_SPEC to provide extra args to cc1 and cc1plus
+ or operating system specific extra switch-translations. */
+#ifndef OS_CC1_SPEC
+#define OS_CC1_SPEC ""
+#endif
+
/* config.h can define CC1PLUS_SPEC to provide extra args to cc1plus
or extra switch-translations. */
#ifndef CC1PLUS_SPEC
@@ -1194,7 +1200,7 @@ proper position among the other output files. */
static const char *asm_debug = ASM_DEBUG_SPEC;
static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC OS_CC1_SPEC;
static const char *cc1plus_spec = CC1PLUS_SPEC;
static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
static const char *link_ssp_spec = LINK_SSP_SPEC;
How does Ada get its default TLS model?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On Wed, 20 Jul 2022, Sebastian Huber wrote: > How does Ada get its default TLS model? You shouldn't need to do anything special, GCC automatically selects initial-exec or local-exec for non-PIC (including PIE). Alexander
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20/07/2022 13:41, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
I am not sure, for this test program:
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
I get:
powerpc-rtems6-gcc -S -O2 -o - tls.c
.file "tls.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
lis 9,_GLOBAL_OFFSET_TABLE_@ha
addis 10,2,j@tprel@ha
la 9,_GLOBAL_OFFSET_TABLE_@l(9)
addi 10,10,j@tprel@l
lwz 9,i@got@tprel(9)
lwz 10,0(10)
add 9,9,i@tls
lwz 3,0(9)
add 3,3,10
blr
.cfi_endproc
.LFE0:
.size f,.-f
.globl j
.section.tbss,"awT",@nobits
.align 2
.type j, @object
.size j, 4
j:
.zero 4
.ident "GCC: (GNU) 12.1.1 20220711 [master 5efa23f3389]"
.section.note.GNU-stack,"",@progbits
and:
powerpc-rtems6-gcc -S -O2 -o - tls.c -ftls-model=local-exec
.file "tls.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
addis 10,2,i@tprel@ha
addis 9,2,j@tprel@ha
addi 10,10,i@tprel@l
addi 9,9,j@tprel@l
lwz 3,0(10)
lwz 9,0(9)
add 3,3,9
blr
.cfi_endproc
.LFE0:
.size f,.-f
.globl j
.section.tbss,"awT",@nobits
.align 2
.type j, @object
.size j, 4
j:
.zero 4
.ident "GCC: (GNU) 12.1.1 20220711 [master 5efa23f3389]"
.section.note.GNU-stack,"",@progbits
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> On 20/07/2022 13:41, Alexander Monakov wrote:
> > On Wed, 20 Jul 2022, Sebastian Huber wrote:
> >
> >> How does Ada get its default TLS model?
> > You shouldn't need to do anything special, GCC automatically selects
> > initial-exec or local-exec for non-PIC (including PIE).
>
> I am not sure, for this test program:
>
> extern _Thread_local int i;
> _Thread_local int j;
>
> int f(void)
> {
> return i + j;
> }
>
> I get:
[snip]
Thanks, I missed that you are asking about promoting initial-exec to local-exec
rather than x-dynamic to y-exec. There's a pending patch that implements such
promotion based on visibility information:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598017.html
With that patch, you'll get local-exec model for the extern variable 'i' if you
inform the compiler that its definition will end up in the current module:
__attribute__((visibility("hidden")))
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
Thus I would try to enhance the binds_local_p target hook for RTEMS to inform
the compiler that there's no dynamic linking (although apart from TLS variables
I cannot instantly name other places where it would enhance optimization).
HTH
Alexander
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20.07.22 15:01, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
On 20/07/2022 13:41, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
I am not sure, for this test program:
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
I get:
[snip]
Thanks, I missed that you are asking about promoting initial-exec to local-exec
rather than x-dynamic to y-exec. There's a pending patch that implements such
promotion based on visibility information:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598017.html
With that patch, you'll get local-exec model for the extern variable 'i' if you
inform the compiler that its definition will end up in the current module:
__attribute__((visibility("hidden")))
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
Thus I would try to enhance the binds_local_p target hook for RTEMS to inform
the compiler that there's no dynamic linking (although apart from TLS variables
I cannot instantly name other places where it would enhance optimization).
This sounds like an interesting approach in the long run, however, I
need a short term solution which I can back port to GCC 10, 11, and 12.
I guess I will add a
MULTILIB_EXTRA_OPTS = ftls-model=local-exec
to all RTEMS multilib configurations.
In general I think the target hooks are hard to customize for operating
systems.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
