[oe] [PATCH][v3 3/4] uClibc: redo configuration

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Thu Jul 8 22:16:33 UTC 2010


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

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.

cheers,




More information about the Openembedded-devel mailing list