plt for arm gnu thumb

plt for arm gnu thumb

[johnmc]

hello


I have just finished a shared library system using the gnu tools for a
system using  arm thumb code but I have found that there is a problem in
that the plt is produced for arm code and it does not work correctly .
question - can I force the gnu tools to produce thumb code plt.

I am using
arm-elf-gcc (GCC) 4.0.1
GNU ld version 2.16.1

thanks in advance

john mcwhinnie

Re: plt for arm gnu thumb

[Daniel Jacobowitz]

On Tue, Apr 18, 2006 at 01:58:18PM +0200, johnmc@sidsa.es wrote:
> hello
> 
> 
> I have just finished a shared library system using the gnu tools for a
> system using  arm thumb code but I have found that there is a problem in
> that the plt is produced for arm code and it does not work correctly .
> question - can I force the gnu tools to produce thumb code plt.

What is the actual problem?

The PLT will always be in 32-bit instructions, but the linker should
arrange for things to work for PLT calls from Thumb also.

-- 
Daniel Jacobowitz
CodeSourcery

Re: plt for arm gnu thumb

[johnmc]

The problem is this.

Code in thumb mode calls the plt sequence which is in ARM code with a BX
instruction in order to call a function located in a shared library - this
part is ok -
Next the plt sequence accesses the GOT for the address of the function in
the shared library and calls the function - this is the problem the plt is
ARM code but the shared library is THUMB and the microprocessor is still
in ARM mode when it starts to run the shared library thumb code i.e. I can
see the program counter increments in 4 bytes.

john mcwhinnie


> On Tue, Apr 18, 2006 at 01:58:18PM +0200, johnmc@sidsa.es wrote:
>> hello
>>
>>
>> I have just finished a shared library system using the gnu tools for a
>> system using  arm thumb code but I have found that there is a problem in
>> that the plt is produced for arm code and it does not work correctly .
>> question - can I force the gnu tools to produce thumb code plt.
>
> What is the actual problem?
>
> The PLT will always be in 32-bit instructions, but the linker should
> arrange for things to work for PLT calls from Thumb also.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: plt for arm gnu thumb

[Richard Earnshaw]

On Tue, 2006-04-18 at 12:58, johnmc@sidsa.es wrote:
> hello
> 
> 
> I have just finished a shared library system using the gnu tools for a
> system using  arm thumb code but I have found that there is a problem in
> that the plt is produced for arm code and it does not work correctly .
> question - can I force the gnu tools to produce thumb code plt.
> 
> I am using
> arm-elf-gcc (GCC) 4.0.1
> GNU ld version 2.16.1

There's only ever going to be a problem if you try to run on an
Architecture v4T device.  These chips cannot transition to Thumb mode
when loading a PC value from memory, but need instead to use a BX
instruction.  The problem is that for a shared library trampoline we
need to:

 - preserve all of r0-r11, r13 and r14
 - have the 'index' of the called function in ip

There's simply no way to achieve all that efficiently and support proper
interworking on these devices.  (v5 and later chips can swap from ARM to
Thumb on a load into the PC, so there is no problem there).

We investigated this quite thoroughly as part of the EABI development. 
We concluded that given that the standard trampoline would work on all
v4 and earlier chips and all v5 or later chips (ie everything but v4T),
and that on v4T the sequence works if the target of the call is entered
in ARM state, the best solution overall was to mandate that on a v4T
device, the called address must be an ARM instruction (it can transition
to Thumb state immediately thereafter).

In theory this could all be handled by the linker when constructing the
library, but currently the GNU linker does not do this.

R.

Re: plt for arm gnu thumb

[Daniel Jacobowitz]

On Tue, Apr 18, 2006 at 04:13:47PM +0100, Richard Earnshaw wrote:
> There's only ever going to be a problem if you try to run on an
> Architecture v4T device.  These chips cannot transition to Thumb mode
> when loading a PC value from memory, but need instead to use a BX
> instruction.  The problem is that for a shared library trampoline we
> need to:
> 
>  - preserve all of r0-r11, r13 and r14
>  - have the 'index' of the called function in ip
> 
> There's simply no way to achieve all that efficiently and support proper
> interworking on these devices.  (v5 and later chips can swap from ARM to
> Thumb on a load into the PC, so there is no problem there).
> 
> We investigated this quite thoroughly as part of the EABI development. 
> We concluded that given that the standard trampoline would work on all
> v4 and earlier chips and all v5 or later chips (ie everything but v4T),
> and that on v4T the sequence works if the target of the call is entered
> in ARM state, the best solution overall was to mandate that on a v4T
> device, the called address must be an ARM instruction (it can transition
> to Thumb state immediately thereafter).
> 
> In theory this could all be handled by the linker when constructing the
> library, but currently the GNU linker does not do this.

Oh, right; I forgot about this issue.

I did once implement alternate PLT sequences which could target Thumb,
even on v4t.  However, they are mighty awkward, so I would strongly
prefer not to submit the patch.  John, are you really using v4t?

-- 
Daniel Jacobowitz
CodeSourcery

Re: plt for arm gnu thumb

[Richard Earnshaw]

On Tue, 2006-04-18 at 16:45, Daniel Jacobowitz wrote:
> I did once implement alternate PLT sequences which could target Thumb,
> even on v4t.  However, they are mighty awkward, so I would strongly
> prefer not to submit the patch.  John, are you really using v4t?

I'd prefer to see a patch that implemented the wrapping of the called
function rather than changing the PLT sequence... :-)

I'm not sure if --wrap xxx could be used to create suitable trampoline
sequences in a semi-automated mechanism.  Is there a way to achieve the
same effect through a linker script?

R.

Re: plt for arm gnu thumb

[Daniel Jacobowitz]

On Tue, Apr 18, 2006 at 04:49:06PM +0100, Richard Earnshaw wrote:
> I'm not sure if --wrap xxx could be used to create suitable trampoline
> sequences in a semi-automated mechanism.

That would probably affect internal calls too, and we don't need to do
that.

> Is there a way to achieve the same effect through a linker script?

I believe not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: plt for arm gnu thumb

[johnmc]

> 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


compile:
arm-elf-gcc -c -fpic  -mthumb -mthumb-interwork dyn_load_module.c  -o
dyn_load_module.o
arm-elf-gcc -c -fpic          -mthumb-interwork dynamic_arm.c      -o
dynamic_arm.o

shared link:
arm-elf-ld  -shared dyn_load_module.o   dynamic_arm.o   -o prog.out
=================================
here is the code:
dynamic_arm.c
void func_shared_arm(void)
{


   func_shared();


}


dyn_load_module.c
extern void func_shared(void);
static void func_shared_static(void);

int global_var = 0x3333;
int global_var1 = 0xaaaa;
int global_var2 = 0xbbbb;
int global_var3 = 0xeeee;
int global_var4 = 0xffff;
int global_var5 = 0xaaaa;
int global_var6 = 0xaaaa;
int global_var7 = 0xaaaa;
int global_var8 = 0xaaaa;
int global_var9 = 0xaaaa;

static int static_global_var = 0x4444;
static int static_global_var2 = 0x1111;

void func_shared(void)
{

   global_var = 0xff;
   static_global_var = 200;
   func_shared_static();


   int x =1;
}


static void func_shared_static(void)
{
   int x =1;
}
======================================





very simple stuff - ARM function func_shared_arm() - calls - THUMB funtion
func_shared()
but the assembler produced below just looks like RUBBISH!!

ANYONE GOT ANY IDEA WHAT I AM DOING WRONG -



dyn_load_module.s:     file format elf32-littlearm

SYMBOL TABLE:
00000094 l    d  .hash	00000000 .hash
00000150 l    d  .dynsym	00000000 .dynsym
00000310 l    d  .dynstr	00000000 .dynstr
00000410 l    d  .rel.dyn	00000000 .rel.dyn
00000420 l    d  .rel.plt	00000000 .rel.plt
00000428 l    d  .plt	00000000 .plt
00000448 l    d  .text	00000000 .text
000005c8 l    d  .dynamic	00000000 .dynamic
00000658 l    d  .got	00000000 .got
00000670 l    d  .data	00000000 .data
000006a0 l    d  .bss	00000000 .bss
00000000 l    d  .comment	00000000 .comment
00080000 l    d  .stack	00000000 .stack
00000000 l    d  *ABS*	00000000 .shstrtab
00000000 l    d  *ABS*	00000000 .symtab
00000000 l    d  *ABS*	00000000 .strtab
00000000 l    df *ABS*	00000000 dyn_load_module.c
00000698 l     O .data	00000004 static_global_var
0000069c l     O .data	00000004 static_global_var2
00000490 l     F .text	0000001c func_shared_static
00000000 l    df *ABS*	00000000 dynamic_arm.c
00000658 l     O *ABS*	00000000 .hidden _GLOBAL_OFFSET_TABLE_
00000670 g     O .data	00000004 global_var
000004c8 g       *ABS*	00000000 __exidx_end
000005c8 g     O *ABS*	00000000 _DYNAMIC
000006a0 g       *ABS*	00000000 _bss_end__
00000684 g     O .data	00000004 global_var5
000006a0 g       *ABS*	00000000 __bss_start__
000004c8 g       *ABS*	00000000 __exidx_start
0000068c g     O .data	00000004 global_var7
000006a0 g       *ABS*	00000000 __bss_end__
00000448 g     F .text	00000048 func_shared
00000694 g     O .data	00000004 global_var9
00000690 g     O .data	00000004 global_var8
000006a0 g       *ABS*	00000000 __bss_start
00000680 g     O .data	00000004 global_var4
000004ac g     F .text	0000001c func_shared_arm
000006a0 g       *ABS*	00000000 __end__
00000674 g     O .data	00000004 global_var1
00000678 g     O .data	00000004 global_var2
000006a0 g       *ABS*	00000000 _edata
000006a0 g       *ABS*	00000000 _end
00080000 g       .stack	00000000 _stack
00000670 g       .data	00000000 __data_start
00000688 g     O .data	00000004 global_var6
0000067c g     O .data	00000004 global_var3


Disassembly of section .plt:

00000428 <.plt>:
 428:	e52de004 	str	lr, [sp, #-4]!
 42c:	e59fe004 	ldr	lr, [pc, #4]	; 438 <func_shared-0x10>
 430:	e08fe00e 	add	lr, pc, lr
 434:	e5bef008 	ldr	pc, [lr, #8]!
 438:	00000220 	andeq	r0, r0, r0, lsr #4
 43c:	e28fc600 	add	ip, pc, #0	; 0x0
 440:	e28cca00 	add	ip, ip, #0	; 0x0
 444:	e5bcf220 	ldr	pc, [ip, #544]!
Disassembly of section .text:

00000448 <func_shared>:
 448:	b580      	push	{r7, lr}
 44a:	4657      	mov	r7, sl
 44c:	b480      	push	{r7}
 44e:	4f0d      	ldr	r7, [pc, #52]	(484 <.text+0x3c>)
 450:	46ba      	mov	sl, r7
 452:	44fa      	add	sl, pc
 454:	466f      	mov	r7, sp
 456:	b081      	sub	sp, #4
 458:	4b0b      	ldr	r3, [pc, #44]	(488 <.text+0x40>)
 45a:	4453      	add	r3, sl
 45c:	681a      	ldr	r2, [r3, #0]
 45e:	23ff      	mov	r3, #255
 460:	6013      	str	r3, [r2, #0]
 462:	4b0a      	ldr	r3, [pc, #40]	(48c <.text+0x44>)
 464:	4453      	add	r3, sl
 466:	681a      	ldr	r2, [r3, #0]
 468:	23c8      	mov	r3, #200
 46a:	6013      	str	r3, [r2, #0]
 46c:	f810f000 	bl	490 <func_shared_static>
 470:	1f3a      	sub	r2, r7, #4
 472:	2301      	mov	r3, #1
 474:	6013      	str	r3, [r2, #0]
 476:	46bd      	mov	sp, r7
 478:	bc04      	pop	{r2}
 47a:	4692      	mov	sl, r2
 47c:	bc80      	pop	{r7}
 47e:	bc01      	pop	{r0}
 480:	4700      	bx	r0
 482:	0000      	lsl	r0, r0, #0
 484:	0202      	lsl	r2, r0, #8
 486:	0000      	lsl	r0, r0, #0
 488:	0014      	lsl	r4, r2, #0
 48a:	0000      	lsl	r0, r0, #0
 48c:	0010      	lsl	r0, r2, #0
	...

00000490 <func_shared_static>:
 490:	b580      	push	{r7, lr}
 492:	4657      	mov	r7, sl
 494:	b480      	push	{r7}
 496:	466f      	mov	r7, sp
 498:	b081      	sub	sp, #4
 49a:	1f3a      	sub	r2, r7, #4
 49c:	2301      	mov	r3, #1
 49e:	6013      	str	r3, [r2, #0]
 4a0:	46bd      	mov	sp, r7
 4a2:	bc04      	pop	{r2}
 4a4:	4692      	mov	sl, r2
 4a6:	bc80      	pop	{r7}
 4a8:	bc01      	pop	{r0}
 4aa:	4700      	bx	r0

000004ac <func_shared_arm>:
 4ac:	e1a0c00d 	mov	ip, sp
 4b0:	e92dd800 	stmdb	sp!, {fp, ip, lr, pc}
 4b4:	e24cb004 	sub	fp, ip, #4	; 0x4
 4b8:	ebffffdf 	bl	43c <func_shared-0xc>
 4bc:	e24bd00c 	sub	sp, fp, #12	; 0xc
 4c0:	e89d6800 	ldmia	sp, {fp, sp, lr}
 4c4:	e12fff1e 	bx	lr

Re: plt for arm gnu thumb

[Richard Earnshaw]

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.

Re: plt for arm gnu thumb

[johnmc]

Could any one point me in the direction of a document that shows the
diferences between ld 16.1 and 16.92 as the previous linker script that I
was using for the last released version of the linker does not work and I
am trying to write a new one that will work correctly with .92 .

thanks

john mcwhinnei

Re: plt for arm gnu thumb

[Nick Clifton]

Hi John,

> Could any one point me in the direction of a document that shows the
> diferences between ld 16.1 and 16.92 as the previous linker script that I
> was using for the last released version of the linker does not work and I
> am trying to write a new one that will work correctly with .92 .

There is no single document.  The simplest place to look is the NEWS 
files in the gas/ and ld/ sub-directories although these will probably 
not be fine grained enough for you.  You can also try the ChangeLog 
files in these directories (and the bfd/ directory) as these contain a 
more detailed record of the changes.

Failing that. you could try creating a more detailed description of the 
problem you are having and posting it here.  A small, reproducible test 
case always helps.

Cheers
   Nick