This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld relocation problem on ARM (PIC related)
- From: jeroen dobbelaere <jeroen dot dobbelaere at acunia dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 07 Nov 2002 08:55:47 +0100
- Subject: Re: ld relocation problem on ARM (PIC related)
- Organization: ACUNIA
- References: <3DC94246.5000300@acunia.com> <20021106165255.GA14040@nevyn.them.org>
Daniel Jacobowitz wrote:
On Wed, Nov 06, 2002 at 05:24:38PM +0100, jeroen dobbelaere wrote:
[...]
At 0x83e4, 'sl' becomes : 0x815c + (0x83e4+8) = 0x10548
Which is the global offset table.
r1, becomes 0x1c
r3, becomes 0x20
Afterwards, [sl, r1] is loaded :
sl+r1 = 0x10564, which contains a (valid) pointer to the string '%p\n"
Than, [sl, r3] is loaded, sl+r3 = 0x10568, which contains a NULL pointer.
(Thus, &var == NULL !!)
Does it contain a NULL pointer at run time?
root:/usr/src/cvs-others/tmp3# ./a.out
(nil)
You didn't show the dynamic relocations in this binary. The content of
the GOT in the binary can be NULL if there is an appropriate relocation
against var to fill it in.
-
nm -D a.out
00008450 R _IO_stdin_used
w __gmon_start__
U __libc_start_main
U abort
U printf
00008454 R var
-
objdump -R a.out
a.out: file format elf32-littlearm
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
00010554 R_ARM_JUMP_SLOT abort
00010558 R_ARM_JUMP_SLOT __libc_start_main
0001055c R_ARM_JUMP_SLOT printf
-
objdump -r a.out
a.out: file format elf32-littlearm
-
So, the 'var' symbol will not be relocated, nor will it have the correct value at run time...
I guess there are two solutions (from my original mail) :
So, I have the impression that there are two possibilities :
- the location of the symbol is known already, but we let the dynamic linker resolve it
at run time.
-> in this case there should be a symbol added (somehow) to indicate this to the dynamic linker
This symbol has not been added...
- the location of the symbol is known already and we should fill it in here...
-> in this case, we should find out the address of the symbol (in stead of 0).
What would be the prefered solution for this case ? (and how can it be done ;) ? )
Greetings,
--
Jeroen Dobbelaere
Embedded Software Engineer
ACUNIA Embedded Solutions
http://www.acunia.com/aes