[arm-gnu] RE: illegal instruction ARMv7 on omap3evm, with -mthumb option
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



You said

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

Does that mean it generates only ARM if I do not specify -mthumb?
Without that option, why do I still see when I run readelf on the generated executable
    TAG_THUMB_ISA_use: Thumb-2 ?

- Stuart

-----Original Message-----
From: Carlos O'Donell [mailto:carlos@xxxxxxxxxxxxxxxx]
Sent: Monday, May 24, 2010 12:48 PM
To: Stuart Waugh
Cc: arm-gnu@xxxxxxxxxxxxxxxx
Subject: Re: illegal instruction ARMv7 on omap3evm, with -mthumb option

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