[Bug gas/23997] New: PLT32 relocation is off by 4

[nruslan_devel at yahoo dot com]

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 address@hidden");

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 address@hidden") to asm("a: .long 
address@hidden - .")
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 
address@hidden
is off by 4 in the second case.

gcc -Wall -O2 -shared -fpic test.c

the first case is correct:
00000000000004c0 <address@hidden>:
...
00000000000005c0 <a>:
 5c0:   00 ff    
 5c2:   ff           
 5c3:   ff

[5c0 + ffffff00] = 4C0


whereas the second case is off by 4:
00000000000004c0 <address@hidden>:
...
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.