Re: little-endian NPTL-based SH toolchains build, not big-endianones

["Robert P. J. Day" <rpjday at mindspring dot com>]

  ok, here's a bit of a followup to try to figure out why adding NPTL
into the mix causes the bootstrap gcc to lose __thread support when
building for big-endian SH.

  comparing the two NPTL-based builds -- sh3 and sh3eb -- both have
the following excerpts in the output from the early glibc headers
build:

...
checking for __thread... yes
checking for tls_model attribute... yes
...
running configure fragment for sysdeps/sh/elf
checking for SH TLS support... yes
running configure fragment for nptl/sysdeps/unix/sysv/linux
running configure fragment for nptl/sysdeps/pthread
checking for forced unwind support... yes
checking for C cleanup handling... yes
running configure fragment for sysdeps/pthread
running configure fragment for sysdeps/unix/sysv/linux
checking for egrep... (cached) grep -E
checking installed Linux kernel header files... 2.0.10 or later
checking for kernel header at least 2.3.99... ok
running configure fragment for sysdeps/unix/common
running configure fragment for sysdeps/unix
running configure fragment for sysdeps/generic
checking for old glibc 2.0.x headers... no
checking whether -fPIC is default... no
configure: creating ./config.status
config.status: creating config.make
config.status: creating Makefile
config.status: creating config.h
config.status: executing default commands
...

  so i see no noticeable difference in the glibc headers stage WRT
thread support.

  however, skip down to the subsequent bootstrap gcc building stage.
part way thru the configure, in *both* builds, we read:

...
checking for thread.h... no				OK
checking for pthread.h... yes				OK
checking for CHAR_BIT... yes
checking whether byte ordering is bigendian... no	??????
...

  not sure if that last line is significant since it's the same one
printed for *both* builds.  is that referring to the build system or
the target system?  should i be concerned that *both* builds seem to
little endian?  that's potentially a bad thing.

  anyway, we're getting to the good part.  a little further down, we
have the following excerpt from both builds, with only one line
difference:

...
Using the following target machine macro files:
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/sh/little.h  <-----
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/sh/sh.h
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/dbxelf.h
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/elfos.h
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/svr4.h
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/sh/elf.h
        /home/rpjday/unpack/gcc-4.0.2/gcc/config/sh/linux.h
...

the highlighted line is only in the sh3 build, which makes sense since
that's the little endian build.  i just tossed that in to verify that,
at least at this point, the bootstrap gcc configure can still tell the
difference between which endianness it's being configured for.

  and here's the nastiness.  in the sh3 (little endian build):

...
checking assembler for COMDAT group support... yes
checking assembler for thread-local storage support... yes
checking linker -Bstatic/-Bdynamic option... yes
...

however, in the sh3eb build, that same excerpt:

...
checking assembler for COMDAT group support... yes
checking linker -Bstatic/-Bdynamic option... yes
...

uh oh ... where went the "checking assembler for thread-local storage
support" in the sh3eb configure?  i think we've found the problem --
that's where it looks like __thread support is going bye bye.

  thoughts at this point?  i'm riding the edge of my comfort zone in
terms of knowing what i'm doing here.

rday



rpjd

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com