This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)
Jivin Shaun Jackman lays it down ...
> On 6/27/06, David McCullough <david_mccullough@au.securecomputing.com>
> 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:
> >
> > XXXX-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: 4b05 ldr r3, [pc, #20] (bc9c <.text+0xbc9c>)
> bc86: b081 sub sp, #4
> bc88: 4453 add r3, sl
> bc8a: 9300 str r3, [sp, #0]
> ...
> bc9c: 2461 movs r4, #97
> bc9c: R_ARM_GOTOFF32 applet_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: 0000 lsls r0, r0, #0
> 24: R_ARM_GOTOFF32 f
> ...
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com