This is the mail archive of the
mailing list for the GCC project.
ARM thumb interworking hole?
- From: Charles Manning <manningc2 at actrix dot gen dot nz>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 10 Jan 2005 17:31:05 +1300
- Subject: ARM thumb interworking hole?
- Reply-to: manningc2 at actrix dot gen dot nz
I've read up what I can on this, and seen the "it's a binutils problem" style
responses too, but I see something still that seems to me a hole in the
current interworking strategy.
I'm compiling thumb with -mthumb -mthumb-interwork -mlong-calls
I'm using -mlong-calls because the code is split between two memory areas
which are more than 4MB apart.
If I have code that calls a function per function pointer then code is
generated to use a _call_via_rX stub to call the function pointer. The
problem though is that the call to call_via_rx is not a long call, so when ld
tried to do the location it can't span the jump with the limited
capabilities (4MB) of a Thumb branch and we end up with a "relocation
truncated to fit" problem.
It seems to me that this isn't an ld problem since ld can't change a branch
into a long branch (??can it??).
It seems to me that this can be fixed in one of two ways:
1) If -mlong-calls has been specified, then generate a long call to the
2) Why do we need the call_via_rx stub anyway? It seems to me this is only
required if the target address is ARM code that does not return via a "bx
lr". Surely we should be able to assume that if the code is marked as
interworking code, then straght interworking will do the job.