On Tue, Nov 09, 2010, Jérémy Lal wrote:
> >  -mno-thumb-interwork is a bit suspicious; I'm not entirely comfortable
> >  on the architecture revisions and cases where these flags are
> >  explicitly needed, but in any case the toolchain defaults should be
> >  fine.
> 
> It seems the only reason left for that flag is because v8 code complains
> about missing 'blx' instruction when arch is armv4t (the gcc default on 
> debian).
> Reported at
> http://code.google.com/p/v8/issues/detail?id=590

 Apparently the code can not deal with Thumb inter-working for ARMv4T,
 only starting with ARMv5T:
// We do not support thumb inter-working with an arm architecture not supporting
// the blx instruction (below v5t).  If you know what CPU you are compiling for
// you can use -march=armv7 or similar.
#if defined(USE_THUMB_INTERWORK) && !defined(CAN_USE_THUMB_INSTRUCTIONS)
# error "For thumb inter-working we require an architecture which supports blx"
#endif

 the test seems correct for the limitation explained in the comment; I
 can also see some tricky blx handling in the code, so it seems entirely
 plausible that the code wouldn't work on ARMv4T with Thumb
 interworking (blx is ARMv5/ARMv5T+).

 Hence building with -mno-thumb-interwork seems correct with Debian (I
 think the toolchain defaults to -mthumb-interwork) and is truly libv8
 specific.

 I'm a bit surprized that you managed to build for armv4t and using blx;
 in my test, it doesn't work:
echo 'void foo(void) { __asm__ volatile("blx 0"); }' | arm-linux-gnueabi-gcc 
-mthumb -march=armv4t -x c -c - -o /dev/null
/tmp/cc2fO8Ba.s: Assembler messages:
/tmp/cc2fO8Ba.s:25: Error: selected processor does not support Thumb mode `blx 
0'
echo 'void foo(void) { __asm__ volatile("blx 0"); }' | arm-linux-gnueabi-gcc 
-marm -march=armv4t -x c -c - -o /dev/null
/tmp/cc4g7aYh.s: Assembler messages:
/tmp/cc4g7aYh.s:26: Error: selected processor does not support ARM mode `blx 0'


 You could in your rules only pass -mno-thumb-interwork if the target
 doesn't support blx (so pretty much only relevant for ARMv4T, since
 ARMv5 can't be supported in Debian and ARMv5T has blx).  It would be
 possible to test for blx with:
CROSS :=
ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
    CROSS :=  $(DEB_HOST_GNU_TYPE)-
endif

check_asm = $(shell echo 'void foo(void) { __asm__ volatile("$(1)"); }' | 
$(CROSS)gcc -x c -c - -o /dev/null 2>/dev/null && echo 1 || echo 0)

blx_asm := blx 0
has_blx := $(call check_asm, $(blx_asm))

ifneq($(has_blx),1)
# libv8 doesn't support Thumb inter-working without blx
CFLAGS += -mno-thumb-interwork
endif

 and you could also check whether __THUMB_INTERWORK__ is defined etc.,
 but it might be simpler to just test for ARMv4t:
check_cpp = $(shell $(CROSS)cpp -dM -P /dev/null | grep -q '^\#define $(1)' && 
echo 1 || echo 0)

is_v4t := $(call check_cpp,__ARM_ARCH_4T__ 1)

ifeq($(is_v4t),1)
# libv8 doesn't support Thumb inter-working without blx
CFLAGS += -mno-thumb-interwork
endif


 I'm not sure Thumb inter-working is too much of a big deal for the
 current targets: it seems you can't use it on armv4t which is what
 Debian armel targets, and it's mostly not needed on ARMv7+ which is
 what armhf and Ubuntu armel target.  Would probably best not to pass
 the -mno-thumb-interwork flag if you don't need to, but it shouldn't
 affect current targets.

> >  -fno-tree-sink seems to be a workaround for a compiler bug (disabling
> >  an optimization).
> 
> It was, gcc 4.4.5 has fixed the bug.

 Cool; it seems we can drop this one then!

> >  -Wno-psabi is undocumented in my version of gcc.
> 
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
> not fixed in gcc 4.4.5-4.

 Thanks for the pointer; seems like something which can be dropped when
 Debian move to 4.5 as the default gcc.

   Cheers,
-- 
Loïc Minier



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to