Jivin Shaun Jackman lays it down ...
> On 6/27/06, David McCullough <[EMAIL PROTECTED]>
> wrote:
> >Are you using the ld-elf2flt/elf2flt.ld combo ?
> >
> >It lays things out in a known way and has a '-move-rodata' option which
> >will put the rodata in with the .text if it contains no relocation info
> >needed at runtime.
> >
> >Something like this on the link line:
> >
> >-gcc -Wl,-move-rodata
> >
> >The uClinux-dist has this as the default for !MMU systems that can do
> >XIP,
> >
> >Cheers,
> >Davidm
>
> I'm not using ld-elf2flt, but I am using elf2flt.ld.
>
> arm-elf-gcc -mthumb -fPIC -msingle-pic-base -Wl,-q -Telf2flt.ld hello.c -o
> hello
> arm-elf-elf2flt -adp hello hello -o hello.bflt
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
> The ld script that puts .rodata in .text fails, due to GCC referencing
> symbols in .rodata with a GOTOFF32 relocation. So, I used the other
> linker script instead, which put .rodata in .data after the .got. This
> got me as far as an XIP "Hello, world!" working, which is thrilling!
>
> Unfortunately, a more complex application, busybox, which uses bsearch
> and thus a callback function, fails because GCC loads the address for
> the callback function using a GOTOFF32 relocation. In the XIP case
> where .text and .data are separated and .got does not immediately
> follow .text, a GOTOFF32 relocation to a symbol in the .text segment
> is super broken.
>
>bc84: 4b05ldr r3, [pc, #20] (bc9c <.text+0xbc9c>)
>bc86: b081sub sp, #4
>bc88: 4453add r3, sl
>bc8a: 9300str r3, [sp, #0]
> ...
>bc9c: 2461movsr4, #97
> bc9c: R_ARM_GOTOFF32applet_name_compare
>
> Loading the address of the callback function with either a PC relative
> relocation or a GOT (not GOTOFF) relocation would work. Can I prevent
> GCC from using GOTOFF32 relocations to symbols located in the .text
> segment?
>
> Can someone on the list verify with their toolchain that the address
> of a static function is loaded using a GOTOFF32 relocation? The
> following test should suffice. It's interesting to note that if the
> callback function is not static, GCC will use a GOT32 relocation
> instead, which will work.
>
> I'm using binutils 2.17 and gcc 4.1.1.
You could try some experiments using the older toolchain to see how it
puts binaries together etc. AFAIK, thumb and most archs are supported
by it, it provides at least a working reference for fixing a new
toolchain at least,
Cheers,
Davidm
> $ cat f.c
> void g(void (*h)(void)) {}
> static void f(void) { g(f); }
> $ arm-elf-gcc -mthumb -fPIC -msingle-pic-base -c f.c
> $ arm-elf-objdump -rS f.o | tail -3
> 24: lslsr0, r0, #0
>24: R_ARM_GOTOFF32 f
>...
> ___
> uClinux-dev mailing list
> [EMAIL PROTECTED]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [EMAIL PROTECTED]
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
