https://sourceware.org/bugzilla/show_bug.cgi?id=23997
Bug ID: 23997
Summary: PLT32 relocation is off by 4
Product: binutils
Version: 2.30
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
The bug was initially filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 (see the discussion there)
but turns out to be an assembler problem.
Consider the following example for some -fpic -mcmodel=small compiled code.
There is an external function func() for which we store a relative reference
to the corresponding @plt stub in a 32-bit variable.
The following seems to generate correct offsets (@plt is already relative, so
we can probably specify it directly):
void func(void);
asm("a: .long func@plt");
extern int a;
int geta()
{
return a;
}
gcc -Wall -O2 -c -fpic test.c
yields
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000000 R_X86_64_PLT32 func
0000000000000013 R_X86_64_REX_GOTPCRELX a-0x0000000000000004
However, if we change asm("a: .long func@plt") to asm("a: .long func@plt - .")
the generated code is very weird and is off by 4:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000000 R_X86_64_PLT32 func-0x0000000000000004
0000000000000013 R_X86_64_REX_GOTPCRELX a-0x0000000000000004
Specifically, if we generate a shared library, the generated offset to func@plt
is off by 4 in the second case.
gcc -Wall -O2 -shared -fpic test.c
the first case is correct:
00000000000004c0 <func@plt>:
...
00000000000005c0 <a>:
5c0: 00 ff
5c2: ff
5c3: ff
[5c0 + ffffff00] = 4C0
whereas the second case is off by 4:
00000000000004c0 <func@plt>:
...
00000000000005c0 <a>:
5c0: fc
5c1: fe
5c2: ff
5c3: ff
[5c0 + fffffefc] = 4BC
It is quite possible that I am missing something here (and the generated code
is correct) but just want to check if there is any potential bug in the
compiler.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
