[Top][All Lists]

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

[Gcl-devel] Re: function addresses and ld.so

From: Matthew Wilcox
Subject: [Gcl-devel] Re: function addresses and ld.so
Date: Wed, 13 Aug 2003 00:27:42 +0100
User-agent: Mutt/1.4.1i

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

reply via email to

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