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

[Stuart Waugh <stuart@xxxxxxx>]

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)
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.
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

Unfortunately our product is rather complex and proprietary, so I doubt I can supply you with a reproducer.

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?

Thanks,

Stuart

-----Original Message-----
From: Mark Mitchell [mailto:mark@xxxxxxxxxxxxxxxx]
Sent: Monday, May 24, 2010 3:07 PM
To: Stuart Waugh
Cc: Carlos O'Donell; arm-gnu@xxxxxxxxxxxxxxxx
Subject: Re: [arm-gnu] RE: illegal instruction ARMv7 on omap3evm, with -mthumb option

Stuart Waugh wrote:

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

Yes.

> Without that option, why do I still see when I run readelf on the generated executable
>     TAG_THUMB_ISA_use: Thumb-2 ?

You are probably linking in at least one Thumb-2 object file, perhaps
something from one of the run-time libraries.

--
Mark Mitchell
CodeSourcery
mark@xxxxxxxxxxxxxxxx
(650) 331-3385 x713