AHA! why SH big-endian builds lose __thread support
Robert P. J. Day
rpjday@mindspring.com
Sun Nov 13 15:56:00 GMT 2005
(wild guess on my part, so i'm open to comments.)
gcc-4.0.2/gcc/configure:
...
if test -z "$tls_first_major"; then
: # If we don't have a check, assume no support.
else
echo "$as_me:$LINENO: checking assembler for thread-local storage
support" >&5
echo $ECHO_N "checking assembler for thread-local storage support...
$ECHO_C" >&6
...
note how the sh3eb build doesn't even *check* for thread-local
storage support, so it's clear that $tls_first_major is null. and why
is it null? look a bit further up the configure script:
# Thread-local storage - the check is heavily parametrized.
conftest_s=
tls_first_major=
tls_first_minor=
tls_as_opt=
case "$target" in
...
sh-*-* | sh[34]-*-*)
conftest_s='
.section ".tdata","awT",@progbits
foo: .long 25
.text
.long foo@TLSGD
.long foo@TLSLDM
.long foo@DTPOFF
.long foo@GOTTPOFF
.long foo@TPOFF'
tls_first_major=2
tls_first_minor=13
tls_as_opt=--fatal-warnings
;;
uh huh. that case pattern doesn't accept a big-endian target pattern
of sh3eb or sh4eb, does it?
thoughts? is this an actual problem that should be bugzilla'ed?
rday
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list