https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524
Bug ID: 88524 Summary: PLT32 relocation is off by 4 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nruslan_devel at yahoo dot com Target Milestone: --- 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.