This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

ARM thumb interworking hole?


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 
_call_via_rx stub.
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.

-- Charles



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