* plt for arm gnu thumb
@ 2006-04-18 13:06 johnmc
2006-04-18 13:10 ` Daniel Jacobowitz
2006-04-18 15:45 ` Richard Earnshaw
0 siblings, 2 replies; 11+ messages in thread
From: johnmc @ 2006-04-18 13:06 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 13:06 plt for arm gnu thumb johnmc
@ 2006-04-18 13:10 ` Daniel Jacobowitz
2006-04-18 15:14 ` johnmc
2006-04-18 15:45 ` Richard Earnshaw
1 sibling, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2006-04-18 13:10 UTC (permalink / raw)
To: johnmc; +Cc: Richard.Earnshaw, binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 13:10 ` Daniel Jacobowitz
@ 2006-04-18 15:14 ` johnmc
0 siblings, 0 replies; 11+ messages in thread
From: johnmc @ 2006-04-18 15:14 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: binutils
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 13:06 plt for arm gnu thumb johnmc
2006-04-18 13:10 ` Daniel Jacobowitz
@ 2006-04-18 15:45 ` Richard Earnshaw
2006-04-18 15:49 ` Daniel Jacobowitz
1 sibling, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2006-04-18 15:45 UTC (permalink / raw)
To: johnmc; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 15:45 ` Richard Earnshaw
@ 2006-04-18 15:49 ` Daniel Jacobowitz
2006-04-18 16:01 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2006-04-18 15:49 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: johnmc, binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 15:49 ` Daniel Jacobowitz
@ 2006-04-18 16:01 ` Richard Earnshaw
2006-04-18 16:49 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2006-04-18 16:01 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: johnmc, binutils
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-18 16:01 ` Richard Earnshaw
@ 2006-04-18 16:49 ` Daniel Jacobowitz
[not found] ` <4596.195.53.86.158.1145376723.squirrel@webmail>
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2006-04-18 16:49 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: johnmc, binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
[not found] ` <20060419150716.GA13655@nevyn.them.org>
@ 2006-04-20 14:32 ` johnmc
2006-04-20 14:38 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: johnmc @ 2006-04-20 14:32 UTC (permalink / raw)
To: binutils
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-20 14:32 ` johnmc
@ 2006-04-20 14:38 ` Richard Earnshaw
[not found] ` <1507.195.53.86.158.1145536917.squirrel@webmail>
0 siblings, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2006-04-20 14:38 UTC (permalink / raw)
To: johnmc; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
[not found] ` <1145541382.16122.62.camel@pc960.cambridge.arm.com>
@ 2006-04-24 18:23 ` johnmc
2006-04-25 17:19 ` Nick Clifton
0 siblings, 1 reply; 11+ messages in thread
From: johnmc @ 2006-04-24 18:23 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: plt for arm gnu thumb
2006-04-24 18:23 ` johnmc
@ 2006-04-25 17:19 ` Nick Clifton
0 siblings, 0 replies; 11+ messages in thread
From: Nick Clifton @ 2006-04-25 17:19 UTC (permalink / raw)
To: johnmc; +Cc: binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-04-25 16:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-18 13:06 plt for arm gnu thumb johnmc
2006-04-18 13:10 ` Daniel Jacobowitz
2006-04-18 15:14 ` johnmc
2006-04-18 15:45 ` Richard Earnshaw
2006-04-18 15:49 ` Daniel Jacobowitz
2006-04-18 16:01 ` Richard Earnshaw
2006-04-18 16:49 ` Daniel Jacobowitz
[not found] ` <4596.195.53.86.158.1145376723.squirrel@webmail>
[not found] ` <20060418203900.GA23304@nevyn.them.org>
[not found] ` <1178.195.53.86.158.1145458815.squirrel@webmail>
[not found] ` <20060419150716.GA13655@nevyn.them.org>
2006-04-20 14:32 ` johnmc
2006-04-20 14:38 ` Richard Earnshaw
[not found] ` <1507.195.53.86.158.1145536917.squirrel@webmail>
[not found] ` <1145538390.16122.39.camel@pc960.cambridge.arm.com>
[not found] ` <1576.195.53.86.158.1145540607.squirrel@webmail>
[not found] ` <1145541382.16122.62.camel@pc960.cambridge.arm.com>
2006-04-24 18:23 ` johnmc
2006-04-25 17:19 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).