This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM thumb: why call_via_rX?
- From: Adrian von Bidder <avbidder at acter dot ch>
- To: Phil Blundell <pb at nexus dot co dot uk>
- Cc: gcc devel mailing list <gcc at gcc dot gnu dot org>
- Date: 25 Jan 2002 13:17:02 +0100
- Subject: Re: ARM thumb: why call_via_rX?
- References: <1011954323.20978.5.camel@atlas> <1011955308.27690.17.camel@mill>
On Fri, 2002-01-25 at 11:41, Phil Blundell wrote:
> On Fri, 2002-01-25 at 10:25, Adrian von Bidder wrote:
> > Why are calls through function pointers made with the call_via_rX stubs
> > on ARM/thumb? couldn't gcc just generate the bx rX operation inline?
>
> I think this is so that the return address gets set up right. If you do
>
> mov lr, pc
> bx my_func
>
> in Thumb mode, the saved "pc" won't have bit zero set and the return
> from "my_func" will cause a spurious switch back to ARM mode if it's
> interworking-enabled. I guess this is the problem that "blx" was
> intended to solve.
Ok, thank you.
<rant>Why couldn't ARM define the lsb of the pc to be the thumb state
bit, and all (half-)word memory accesses to ignore the lsb of the
address</rant>
> If you aren't doing interworking, at least for the callee, then there
> might not be an issue. I don't know if you can communicate this to GCC
> at the moment though.
If it's sure that gcc does not generate any function returns with bx lr,
but always does mov pc, lr or pop {..., pc} (which seems to be the
case), function calls should be possible with just "mov lr, pc; mov pc,
rX" in the non-interworking case.
>
> > The call_via_rX stubs are problematic for me because one program I
> > should get to work does some fancy copying of code at runtime - where,
> > of course, calls with relative addresses fail. Calls through function
> > pointers have so far (in ARM) worked.
>
> Are you saying that any "b" or "bl" instruction is verboten? Perhaps
> you could be a bit more concrete about what's going on.
pc-relative jumps between copied code and non-copied code are a no-no.
Our CPU has an internal 8K static (fast) RAM, and external (slow) Flash.
So my collegue had the idea of copying the most time-consuming code into
the fast on chip RAM. So, of course, calls between non-copied and copied
code with bl (such as calling call_via_rX) fail horribly.
[Note: for me, the discussion has become mostly academic, as I've been
able to circumvent the problem by rearranging the program. So don't
waste your time. But I'm still convinced that gcc is far from bringing
out the full potential of thumb code.]
greets from Zürich
-- vbi