gcl-devel
[Top][All Lists]
Advanced

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

Re: 2.6.2 postponed .. (was Re: [Gcl-devel] RE ld from 2.14.90.0.8 puts


From: Camm Maguire
Subject: Re: 2.6.2 postponed .. (was Re: [Gcl-devel] RE ld from 2.14.90.0.8 puts no value into undefined symbols)
Date: 28 Feb 2004 12:19:06 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:

> >
> 
> In any case it is very good that we steped on this
> mine so early.
> 

Indeed.  You are our early warning system!

> Your fix works to me!  I was able to rebuld ANSI GCL and
> Maxima CVS using this GCL without any trouble.
> I'll try Axiom later today.
> 

Great!  Most debian architectures survived the change as well, with
the exception of sparc and mips.  Sparc has symbols with periods in
the names, like .div, which won't compile as C initializers.  mips has
an unknown relocation error.  In general, the fix is not very
robust/portable.  I'm hoping someone can suggest a better way.
(Aurelien?)

The idea is that compiled lisp objects can contain references to
symbols which are in external shared libraries, even when no such are
explicitly mentioned in the C source.  The most common in this latter
category are related, I think, to the C builtin functions of gcc,
i.e. .div on sparc, __moddi3 on i386, etc.  The most common symbols
needed which are explicitly mentioned in the C source include
setjmp and some trig math functions.  The base image needs to know how
to relocate these symbols to the right place on image load.

As the problem is not completely under the control of the lisp
compiler (i.e. tracking what exactly goes into the C source), we've
taken a heuristic approach, and simply asserted that no such symbols
will ever be needed which are not already found to be needed in the
objects in the o/ directory.  this seems reasonable, but is by no
means guaranteed.  We've also asserted, wrongly on sparc and mips, that
the addresses of these symbols in the executable can be captured
within C by referring to the symbol by name.  Lastly we have asserted
without testing (so far) that using this address captured within C
will produce the same result as reading the symbol value inserted by
older versions of the linker.  This has not yet been tested as the
mere existence of the code to capture the addresses within C restores
the old linker behavior, which we use preferentially if present.

It would be much nicer if there were simply a ld option 'keep (plt
address) values in undefined symbols'.  Perhaps some friends of GCL
could beseech the binutils people for this.

Take care, 




> -- 
>       Vadim V. Zhytnikov
> 
>        <address@hidden>
>       <address@hidden>
> 
> 
> 
> _______________________________________________
> 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




reply via email to

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