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: function addresses and ld.so


On Tue, Aug 12, 2003 at 06:24:47PM -0400, Camm Maguire wrote:
> GCL stores addresses of its functions in data structures allocated in
> the normal way in its .data section.  It then runs an unexec routine
> which saves the memory image including these addresses to a file.
> When the file is then later run against ostensibly compatible but
> different shared library versions, occasionally the stored function
> addresses will no longer point to the correct function.
> 
> One mechanism I've identified leading to this behavior is that on
> ia64, for example, passing a function address as an argument to
> another function which stores it in a saved variable does not actually
> pass the address, but rather an address to some region governed
> directly by ld.so, at which location the desired function address is
> to be found.

Right.  ia64, parisc and ppc64 all use function descriptors (aka fat
function pointers).

> Somehow the compiler has instructed the code to look in this ld.so
> space for the function address, and adopts the convention that when
> one calls the function via (*fn)(...), one really calls the address
> pointed to by fn as opposed to fn itself.  
> 
> So when for example I run the program against two different but
> compatible versions of shared libraries, ldd reports a different
> mapping on ia64 in the 0x20000... range, and while fLformat has the
> same address 0x40000000001a9390 in both instances, and while the
> stored address in the calling variable has the same value of
> 0x200000000003c358 in both instances, the address stored at the latter
> location is not reliably the former unless ld.so makes the same
> mapping for the libs, which presumably can only be guaranteed by
> using identical versions.
> 
> Is there a gcc compiler option which can disable this behavior, and
> pass the function addresses as they are?

Mmm.. don't think so.  It's part of the ABI.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


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