axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] A modest proposal


From: Camm Maguire
Subject: Re: [Axiom-developer] A modest proposal
Date: 03 Jul 2007 17:41:28 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Ondrej Certik" <address@hidden> writes:

> > Of course, it could be argued that portability to all these machines
> > is not all that important, in which case we can configure the package
> > accordingly.
> 
> I am just curious - isn't it a problem for Debian build servers, that
> the package builts for 12 hours or even more?
> 

Were it only that simple.  Typically, many, many failures are required
to get a working build on a lesser known machine.  gcl/axiom flushes
out instabilities in gcc, binutils, and several other very low-level
parts of the toolchain.  That said, getting all the builds working
flushes out bugs in gcl too.

Witness the issues at present: gcl switch statements apparently
generate bogus jump table assembler on mips, gcc-object-inserted
symbols __divq/__remq on alpha are apparently uwrappable (*), new
GPREL_32 relocs in the new .rodata section needed support on alpha,
new GNU_HASH section types required binutils patches, etc.

(*) As you know, GCL loads object (.o) files into a running image,
which can then be dumped and executed later.  It therefore needs the
ability to relocate all symbols in the .o file.  Relocating to
addresses in external shared libraries is dangerous, as the lib may
not be in the same place on image restart.  2.6.x had a plt mechanism,
which attempted to force gcc to provide local addresses by compiling
in functions using the addresses of the external functions.  This
broke with subsequenct gcc developements, so even with the plt,
relocations were being set to shared library addresses on some
machines.  Now, 2.7.0 redirects all such calls through a pointer in
the C source which is reset on image startup.  __divq and the like,
alas, have no representative in the C source, and cannot be handled
thus.  Ideally, we can define a wrapper function and relocate to that,
but this procedure has been problematic with mcount (for example) on
s390 and ppc.  (just a taste ... :-)

Take care,

> Ondrej
> 
> 
> 

-- 
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]