ARM setjmp.S multilib issue

   I am using newlib-1.15.0 in a multilib configuration
built together with 
gcc-4.1.1 (as in "newlib gets built by the gcc multilib
build").

   Everything has been working out fine, but I have recently
stumbled into 
a problem with setjmp.S: it gets built in multiple variants
by the gcc 
multilib mechanism. However, setjmp.S is for some reason
*never* assembled 
into thumb -- the thumb multilib variants all contain an ARM
version of 
setjmp.o

   Anyone else able to confirm/deny this in e.g. 1.16?

Best regards,
ali

Anders Lindgren wrote:
>   I am using newlib-1.15.0 in a multilib configuration
built together 
> with gcc-4.1.1 (as in "newlib gets built by the
gcc multilib build").
>
>   Everything has been working out fine, but I have
recently stumbled 
> into a problem with setjmp.S: it gets built in multiple
variants by 
> the gcc multilib mechanism. However, setjmp.S is for
some reason 
> *never* assembled into thumb -- the thumb multilib
variants all 
> contain an ARM version of setjmp.o
>
>   Anyone else able to confirm/deny this in e.g. 1.16?
>
> Best regards,
> ali
Anders,

  There has been a recent fix to setjmp.S with regards to
the __thumb2__ 
flag.  I would suggest trying the new file out.

  Otherwise, a few things to check.  First off, run the
compiler with 
--print-multi-lib to verify the thumb variant is associated
with the 
appropriate option.  Go to your newlib build directory and
traverse to 
the thumb/newlib/libc/machine/arm directory and look at the
Makefile.  
It should have a line in it which sets CC = ..... -mthumb

  Finally, verify that the compiler is actually setting the
__thumb__ or 
__thumb2__ flags for newlib to check.

-- Jeff J.