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

[Carlos O'Donell <carlos@xxxxxxxxxxxxxxxx>]

On 24/05/10 03:02 PM, Stuart Waugh wrote:
> 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)

It generates Thumb-2 code if you specify -march=armv7-a and -mthumb. 
It never generates ARM mode code if you specify -mthumb.

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

You never need to specify -mthumb-interwork anymore, the linker 
automatically takes care of creating stubs between thumb mode and arm 
mode code.

> 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?

Directly from the compiler manual included with the tools:
~~~
-mthumb
    Generate code for the Thumb instruction set. The default is to 
use the 32-bit ARM instruction set. This option automatically enables 
either 16-bit Thumb-1 or mixed 16/32-bit Thumb-2 instructions based on 
the -mcpu=name and -march=name options.
~~~

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

I have actually never seen a binary that required this option. Is your 
binary actually larger than 64MBs?

Normally the linker will insert veneers automatically if your Thumb 
mode code needs to branch farther than ~16MB (25-bit signed jump).

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

Yes, and no. Yes it caused SIGSEGVs. No, it was not a small offset, it 
was a large offset. You could easily see the target of the stub was 
pointing to invalid high memory.

> 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

As I mentioned before, you don't need -mthumb-interwork anymore.

> Does this make sense?

Yes. Updating will bring in bug fixes.

Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
carlos@xxxxxxxxxxxxxxxx
(650) 331-3385 x716