Re: plt for arm gnu thumb

[Richard Earnshaw <rearnsha@arm.com>]

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.