* 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
[parent not found: <4596.195.53.86.158.1145376723.squirrel@webmail>]
[parent not found: <20060418203900.GA23304@nevyn.them.org>]
[parent not found: <1178.195.53.86.158.1145458815.squirrel@webmail>]
[parent not found: <20060419150716.GA13655@nevyn.them.org>]
* 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
[parent not found: <1507.195.53.86.158.1145536917.squirrel@webmail>]
[parent not found: <1145538390.16122.39.camel@pc960.cambridge.arm.com>]
[parent not found: <1576.195.53.86.158.1145540607.squirrel@webmail>]
[parent not found: <1145541382.16122.62.camel@pc960.cambridge.arm.com>]
* 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).