[arm-gnu] RE: illegal instruction ARMv7 on omap3evm, with -mthumb option

["Woodruff, Richard" <r-woodruff2@xxxxxx>]

You might also try adding thumb errata work around flag
            --fix-cortex-a8

Disabling control register ‘Z’ bit would also be a test.

Regards,
Richard W.

________________________________
From: Stuart Waugh [mailto:stuart@xxxxxxx]
Sent: Monday, May 24, 2010 2:03 PM
To: arm-gnu@xxxxxxxxxxxxxxxx; carlos@xxxxxxxxxxxxxxxx
Subject: [arm-gnu] illegal instruction ARMv7 on omap3evm, with -mthumb option

I have been encountering a strange illegal instruction with our code ported to ARMv7 OMAP 3550 (Cortex 8).

We see illegal instructions when using static linked libraries. We never see this with dynamic. In gdb we see Seg Faults that appear to be due to addresses being off a small number of bytes. I suspect this is due to an incorrect compiler setting on our part.

We were using -mthumb -march=armv7-a -mfpu=neon -msoft-float
The problem mostly cleared up adding -mthumb-interwork -mlong-calls
The problem vanished by removing the -mthumb compile option

This leads to five  usage questions:


1.   Does the Lite cross-compiler generate only thumb-2 for ARMv7?  readelf indicates this (TAG_THUMB_ISA_use: Thumb-2)

2.   Should we be using –mthumb-interwork option since the libc shared object is fully ARM?

3.   What does –mthumb option do? Does it mean 16-bit thumb is to be used? If it’s not use is it fully thumb-2, 32-bit?

4.   Without –mthumb option, does it make sense to still use –mlong-calls

5.   Does the bug fixed in Lite 2010q1-202 “Incorrect linker-generated functions” impact the symptoms we are seeing?

My thinking is we should go to Lite 2010q1-202 and to work with AMRv7 OMAP 3550 set the options to
      -march=armv7-a -mfpu=neon -msoft-float -mthumb-interwork

Does this make sense?

Regards,

Stuart