This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)


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

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.

Cheers,
Shaun

$ 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
       ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]