Problem with PIC support

[Bo Thorsen <bo at suse dot de>]

There is a problem with the PIC support on the x86-64 architecture. When
linking this small testcase:

	movq aaa@GOTPCREL(%rip), %rax
	movq bbb@GOT(%rip), %rax

	.globl aaa
aaa:
	.globl bbb
bbb:

the GOT is filled with 5 8-byte addresses, all zero. The first three are
supposed to be zero, but the next two should not be.

I have compared with a small i386 testcase:

	movl aaa@GOT, %eax
	movl bbb@GOT, %eax

	.globl aaa
aaa:
	.globl bbb
bbb:

Printing out a lot of internal data in libbfd shows that sgot->contents
gets incremented after the individual relocations are performed but before
finish_dynamic_sections is called. It gets incremented with the space
needed for the entries in the got. You can see this with some of the
debuggin info (from i386):

/data/test> as -o pic32.o pic32.s ; ld -o o32.o pic32.o
ld: warning: cannot find entry symbol _start; defaulting to 08048074
Relocate: sgot->contents: 135090812
Relocation of aaa: 134512766 at 0
Relocate: sgot->contents: 135090812
Relocation of bbb: 134512766 at 4
Finish: sgot->contents: 135090820

This incrementation does not happen on x86-64:

/data/test> x86_64-unknown-linux-as -o pic.o pic.s; x86_64-unknown-linux-ld
 -o o.o pic.o
x86_64-unknown-linux-ld: warning: cannot find entry symbol
_start; defaulting to 00000000000010b0
GOTPCREL: sgot->contents: 135220488
Relocation of aaa: 4286 at 0
GOTPCREL: sgot->contents: 135220488
GOT32: sgot->contents: 135220488
Relocation of bbb: 4286 at 0
GOT32: sgot->contents: 135220488
Finish: sgot->contents: 135220488

Could this difference between the ports be related to the got filling
problem?

As the x86-64 behavious seems wrong, any ideas on how to fix it?

One more problem is showing in the debugging output from x86-64: The
offset is zero for both the relocations and not 8 as the second one should
be. Why does this happen?

Thanks in advance for any help offered. These bugs have been bugging me
for some time now. The more elaborate you can be on showing me the
problems here, the better. I'm still very far from really understanding
libbfd.

(To reproduce - even compile - this, you need a completely fresh update
since it won't be possible without the latest patches from Jan Hubicka and
myself.)

Bo.

-- 

     Bo Thorsen                 |   Lahnsgade 31, st.
     Free software developer    |   5000 Odense C
     SuSE Labs                  |   Denmark