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: What is R_X86_64_GOTPLT64 used for?


On Tue, Nov 18, 2014 at 5:12 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 17 Nov 2014, H.J. Lu wrote:
>
>> It has nothing to do with large model.
>
> Yes, I didn't say so.  I've used it only to force GCC to emit @GOT relocs
> (otherwise it would have used @GOTPCREL) to disprove your claim.

Well, it was just on paper.  Linker never implemented such GOTPLT optimization:

[hjl@gnu-6 simple]$ cat main.S
.file "main.c"
.text
.globl _start
.type _start, @function
_start:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
pushq %rbx
subq $24, %rsp
.L2:
.cfi_offset 3, -24
leaq .L2(%rip), %rbx
movabsq $_GLOBAL_OFFSET_TABLE_-.L2, %r11
addq %r11, %rbx
movabsq $foo@GOTPLT, %rax
movq (%rbx,%rax), %rax
movq %rax, -24(%rbp)
movq -24(%rbp), %rax
call *%rax
movabsq $foo@PLTOFF, %rax
addq %rbx, %rax
call *%rax
addq $24, %rsp
popq %rbx
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _start, .-_start
.ident "GCC: (GNU) 4.8.3 20140911 (Red Hat 4.8.3-7)"
.section .note.GNU-stack,"",@progbits
[hjl@gnu-6 simple]$ cat foo.c
void
foo (void)
{
}
[hjl@gnu-6 simple]$ make
gcc -fpie -mcmodel=large -c -o main.o main.S
gcc -fpic   -c -o foo.o foo.c
./usr/local/bin/ld -shared -o libfoo.so foo.o
./usr/local/bin/ld -o foo main.o libfoo.so
readelf -r main.o

Relocation section '.rela.text' at offset 0x290 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000012  00090000001d R_X86_64_GOTPC64  0000000000000000
_GLOBAL_OFFSET_TABLE_ + 9
00000000001f  000a0000001e R_X86_64_GOTPLT64 0000000000000000 foo + 0
000000000037  000a0000001f R_X86_64_PLTOFF64 0000000000000000 foo + 0

Relocation section '.rela.eh_frame' at offset 0x2d8 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000020  000200000002 R_X86_64_PC32     0000000000000000 .text + 0
readelf -r foo

Relocation section '.rela.dyn' at offset 0x268 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
0000006004b8  000200000006 R_X86_64_GLOB_DAT 0000000000000000 foo + 0

Relocation section '.rela.plt' at offset 0x280 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
0000006004d8  000200000007 R_X86_64_JUMP_SLO 0000000000000000 foo + 0
[hjl@gnu-6 simple]$

>> The same thing happens to small model.  We may be to able optimize it,
>> independent of GOTPLT.
>
> Yes, if we were to optimize this, the difference between GOT and GOTPLT
> would be very minor.
>

I will give it a thought.  But we don't need GOTPLT for it.  We should obsolete
GOTPLT.

-- 
H.J.


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