This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] ARM support for long calls
- From: Paul Brook <paul at codesourcery dot com>
- To: binutils at sourceware dot org
- Cc: Christophe LYON <christophe dot lyon at st dot com>
- Date: Thu, 3 Apr 2008 01:59:27 +0100
- Subject: Re: [patch] ARM support for long calls
- References: <47F1051A.3030107@st.com> <200804011510.45346.paul@codesourcery.com> <47F3A641.3090706@st.com>
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