On Thu, Jul 08, 2010 at 03:03:04PM -0700, Khem Raj wrote: >On Thu, Jul 8, 2010 at 2:34 PM, Phil Blundell <[email protected]> wrote: >> On Thu, 2010-07-08 at 14:31 -0700, Khem Raj wrote: >>> On Thu, Jul 8, 2010 at 2:29 PM, Phil Blundell <[email protected]> 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, _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
