This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: plt for arm gnu thumb
On Thu, 2006-04-20 at 10:03, johnmc@sidsa.es wrote:
> > On Wed, Apr 19, 2006 at 05:00:15PM +0200, johnmc@sidsa.es wrote:
> >> Hi Daniel
> >
> > Please, if you have further questions, send them to the list and not to
> > me personally. That's more useful for everyone.
> >
> > Also, if you want help, I recommend more precise reports: command lines
> > used, test cases, objdump output for what appears to be wrong.
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery
> >
>
> hello
>
> A couple of days ago I found out that the "procedure linkage table" - plt
> produced when transitioning
> on an ARM V4t chip does not function.
> So the suggestion was that I design my code so that the transition from
> the plt is to an ARM compiled
> function that then can call a THUMB compiled function.
>
> I have been trying to do this and it does not seem to work either - or
> maybe I am not doing it properly as
> I have no previous experience using interworking.
>
> In order to test this I have built a small test shared library .
> Here are the commands I used to build this SHARED LIBRARY.
>
> The 2 modules used are
> dyn_load_module.c - THUMB
> dynamic_arm.c - ARM
>
You'll need to construct something like the following:
Your main application code:
int func_real(void) __attribute__((visibility("hidden")));
int x;
int func_real(void)
{
return x + 1;
}
Compile that with -mthumb -mthumb-interwork etc.
Then the wrapper file:
int func_real(void) __attribute__((visibility("hidden")));
int func(void)
{
return func_real();
}
Compile that with (at least) -O2 -mthumb-interwork (but not thumb).
Now, when you build your shared library, you'll get:
00000524 <func_real>:
524: 4652 mov r2, sl
...
00000548 <func>:
548: eaffffff b 54c <__func_real_from_arm>
0000054c <__func_real_from_arm>:
54c: e59fc004 ldr ip, [pc, #4] ; 558 <__func_real_from_arm+0xc>
550: e08cc00f add ip, ip, pc
554: e12fff1c bx ip
558: ffffffcd undefined instruction 0xffffffcd
You'll note that the linker has inserted a suitable trampoline sequence
to get from ARM to thumb state when there is a branch instruction. You
could hand-optimize this if you wanted to write some assembly code
yourself, for example:
.text
.align 2
.global func
.type func, %function
func:
ldr ip, [pc, #4]
1: add ip, ip, pc
bx ip
.word func_real - . - (1b + 8 - .)
.size func, .-func
(you could write this as a macro and then generate stubs for each
routine you need to export).
Unfortunately, there appears to be a bug in the handling of the
R_ARM_REL32 relocation in the linker that means that the sequence above
doesn't work as intended (the bottom bit in the relocated value is not
correctly set to create a suitable Thumb-ISA target). You can work
around this by coding your trampoline as
func:
ldr ip, [pc, #4]
1: add ip, ip, pc
orr ip, ip, #1
bx ip
.word func_real - . - (1b + 8 - .)
R.