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

[Camm Maguire]

Greetings, and thanks!  OK presuming you are correct, there seems to
be no way to ensure with GCL's current design that this problem will
not arise *on these platforms* (ia64, hppa, ppc64, darwin).  (I.e.,
Vadim, this does not explain what you are seeing, AFAICT).  Therefore,
Debian gcl/maxima/acl2 packages need a rebuild when the underlying
shared libraries change (currently libc, libm, libreadline4,
libncurses5, and libgmp3), at least on these architectures.

Given this, the prudent course of action for the Debian packages is to
install exact versioned dependencies on their shared libs, i.e. a
dependency of the form libc6 (= 2.2.4-4), etc.  I don't really know
how this will play with the autobuilder system.  What would be ideal
is for a new libc upload to automatically trigger a rebuild of
packages with these types of dependencies, but I doubt this is in
place.  Short of this, what kind of mechanism could be employed to
ensure that gcl/maxima/acl2 packages are rebuilt, at least on these
platforms, when the underlying shared libs change?  I suppose I could
subscribe to the package tracking system for these libs and rerelease
accordingly, but I'm hoping for a method requiring less manual
intervention.

The other issue is that, especially in the case of acl2, the build
time is quite large on slow boxes, making frequent rebuilds
undesirable.  I could link the libs in statically, but this seems
wasteful. 

Advice appreciated

Matthew Wilcox <address@hidden> writes:

> 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
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah