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

[Carlos O'Donell <carlos@xxxxxxxxxxxxxxxx>]

On 25/05/10 01:13 PM, Stuart Waugh wrote:
> Thanks guys. I did some experimenting and I can tell you the following:
>
> 1. the bug fix in 2010q1-202 does not address the problem we see
>       * it appears to be a small offset address problem
>           (we see it between 1st&  2nd instruction in gdb)

How small is the offset, one byte? The thumb2 symbols have the thumb 
bit set making them look like odd addresses.

Therefore if you have assembly that does *not* mark a sequence as ARM 
or Thumb, then you might jump to the wrong location.

We see this frequently with hand written assembly that doesn't use 
".type   foo, %function" to mark functions, and doesn't additionally 
use ".code 16", ".thumb", or ".thumb_func" directives to mark Thumb2 
code sequences.

> 2. building our program as ARM works, telling me it is an interwork problem
>       * this is what we decided to do, lower risk, since a thumb2 app will
>         run on our ARM generated code. So far does so without issue.
>       * it is my take the risk is lower, since the system libs are ARM, to be full ARM
>         since interwork is pushed down to the apps only.

Yes, this is a lower risk option.

> 3. The -mthumb-interwork option has a significant impact when we used -mthumb
>       * this tells me the option is not fully deprecated
>       * this tells me there may be a bug in the generated thumb-ARM stubs

What is impacted by using -mthumb-interwork? Exactly what changes?

> However If I gave you an object file with the -mthumb option, could you tell if the stub code is correct? What would you need? Or alternately how can we do that?

The ARM->Thumb and Thumb->ARM stubs are easy to see, they are labeled 
as such and you can see them in your program. When debugging does the 
small offset address problem arise after stepping through a stub? If 
the error is intermittent, then it is not a stub problem.

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