bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/10009] New: Conflict between MIPS PLTS and abicalls stubs


From: cburgess at qnx dot com
Subject: [Bug ld/10009] New: Conflict between MIPS PLTS and abicalls stubs
Date: 26 Mar 2009 13:32:45 -0000

We have an issue where a nonPIC binary that is

* calling a function in a shared object
* calling another function in a shared object, which references the address of
the first function, saving it as a function pointer.
* later, calling yet another function (in a shared object) which invokes the
function pointer.

Because the executable itself doesn't refer directly to the address of the
function, an abicalls stub is generated.
However, since the canonical address of the function is, as I understand it, the
address of the stub in the
executable's .MIPS.stubs section, when the function invocation is performed it
will mess up because the $gp
is pointing at the shared objects got, whereas the stub assumes that it points
at the executables got.

If a the address of the function is taken in the executable, then all is well
since this generates a PLT
entry with STO_MIPS_PLT.

Attached is an example application, which I've tried to comment as clearly as
possible.

This is with binutils 2.19, under QNX 6.4.1

Regards,

Colin

-- 
address@hidden

-- 
           Summary: Conflict between MIPS PLTS and abicalls stubs
           Product: binutils
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: unassigned at sources dot redhat dot com
        ReportedBy: cburgess at qnx dot com
                CC: bug-binutils at gnu dot org
  GCC host triplet: i386-linux-gnu
GCC target triplet: mips-unknown-qnx6.4.0


http://sourceware.org/bugzilla/show_bug.cgi?id=10009

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]