This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] ARM support for long calls


On Wednesday 02 April 2008, Christophe LYON wrote:
> Thanks for your feedback.
>
> On 01.04.2008 16:10, Paul Brook wrote:
> > There are several issues with this implementation:
> >
> > - ARMv4t arm->thumb interworking is broken (You have to use bx to switch
> > modes, ldr pc does not work). You also get stray __foo_from_arm symbols
> >
> > - ARMv4t thumb->arm interworking is broken. It generates blx
> > instructions, which arm ARMv5 only.
>
> I didn't really focus on ARMv4t because we use only more recent
> variants. Would a patch doing nothing for ARMv4t be acceptable?

ARMv4t CPUs are still very common in practice (I believe they're still the 
most common core by volume), so I think it's worth making them work.  I 
suspect the majority of toolchains still default to ARMv4t.

It's worth noting that many of the issues with ARMv4t are still present on 
ARMv5. For example R_ARM_JUMP24 relocations (branches and conditional calls) 
still require interworking veneers. Only R_ARM_CALL relocations 
(unconditional calls) are eligible for blx conversion.

Either way, it's wrong to generate broken code. Anything we haven't got round 
to implementing should result in an error, not bad code.

> > - You can't use ARM code unless the object already does so (it won't work
> > on M profile devices).
>
> OK. What is the appropriate query to check M variants? From what I see,
> in the linker we can only check Tag_CPU_arch whose value TAG_CPU_ARCH_V7
> is not precise enough.

To a first approximation you may only generate ARM code if the input objects 
already contains ARM code. Objects contain separate attributes for the 
architecture profile(A, R, M, nonspecific), architecture revision (v5, v6, 
etc), and which modes are used.

>...
> > - BE8 mode is broken.
>
> I wasn't aware of this mode either. From what I understand, I should
> just call put_arm_insn() rather than bfd_put_32() ?

For instructions, yes. Remember that constant pools should not be swapped.
This a bit of a hack because veneers are populated after we do the normal BE8 
swapping.

Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]