On Thu, Jul 8, 2010 at 3:16 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On Thu, Jul 08, 2010 at 03:03:04PM -0700, Khem Raj wrote:
>>On Thu, Jul 8, 2010 at 2:34 PM, Phil Blundell <philb@gnu.org> wrote:
>>> On Thu, 2010-07-08 at 14:31 -0700, Khem Raj wrote:
>>>> On Thu, Jul 8, 2010 at 2:29 PM, Phil Blundell <philb@gnu.org> wrote:
>>>> > On Thu, 2010-07-08 at 14:03 -0700, Khem Raj wrote:
>>>> >> If I am not wrong you can still do interworking and not have bx (using
>>>> >> mov pc,lr)
>>>> >
>>>> > That's not an interworking instruction in ARMv4T, and I don't think it
>>>> > is in ARMv5TE either.  You might be thinking of pop {pc}, which is
>>>> > interworking in ARMv5TE, but even this is not interworking in v4t.
>>>>
>>>> tst lr, #1
>>>> moveq pc, lr
>>>> bx lr
>>>>
>>>> Thats how its done on armv4 for EABI
>>>
>>> Right, but the MOV in that case is not an interworking instruction; it's
>>> just a way to avoid executing BX when you don't actually need to switch
>>> mode, so that you can create a library which still works in an ARM-only
>>> environment.
>>>
>>> The final BX in that sequence is mandatory in order for it to actually
>>> function as an interworking return.
>>
>>right you are. yes bx is always needed for thumb interworking. So I guess
>>for uclibc we can rely on THUMB_INTERWORK distro feature if set correctly.
>
> AFAIR eabi implies thumb, thumb makes interwork possible, interwork
> imples bx but my memory could fail me on this.

eabi does not imply thumb. EABI is supported on armv4 which does not have
thumb.

>
> Can you, khem, think of a set of "thumb" and "interwork" (and
> potentially "bx" for HW that supports it, like IIRC all e.g. cortex
> onward based designs) in DISTRO_FEATURES and MACHINE_FEATURES that can
> be used generically?
>
> A first step would be to just resuse the infrastructure in this thread,
> later on we could think about some sort of combined_feature mechanism to
> properly setup arm ontop of this proposed infrastructure.

I think we need thumb_interwork distro_feature which we could use here
here is a patch that distros would need.




>
> cheers,
>