[Top][All Lists]

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

[Gcl-devel] Pure bfd checked in

From: Camm Maguire
Subject: [Gcl-devel] Pure bfd checked in
Date: Wed, 12 Jun 2002 22:33:48 -0400

Greetings!  Just a notice to some fairly extensive changes I've checked
into cvs.  Please check them out.  With these, gcl/maxima build
without failure on powerpc-linux!  And I bet others as well.  The goal
here is not to add functionality, but to increase portability.

1) At some point, I'd like configure to generate all info in the .h
   and .defs files, but to still keep these files to override configure
   defaults only, not as at present where they supply critical info which cannot
   be ascertained otherwise.  Right now, these files do override
   anything configure might detect, and this should remain.

2) i386-linux defaults to using the bfd for both initial symbol table
   building and fasloading.  Use the --disable-bfd option to configure if you
   want the old elf behavior.  I'm making this the default as I'd like
   to shake out the bugs if any in
   bfd support.  No errors found in maxima make test with this turned

3) Added more gcc optimization to default i386 case.  Works fine.

4) bfd uses a hash table to map symbols to addresses, which should be
   more efficient than the old binary tree lookup.  Eventually, we
   could use this for the combined_table in fat_string.c as well,
   which is used for profiling.  There seems to be support for
   internal gcl profiling as well as gprof.  Anyone have experience
   with either?  I did a little checking with the internal profiling,
   as explained in doc/enhancements, and it seems to work with the new
   symbol stuff.  Speaking of which -- why aren't we
   compiling/shipping profile.(lsp,o)?

5) I think we need to look into the modularity of gcl again.  I'd like
   to make use of the autoload mechanism used for tkl.o to get more of
   these useful but optional features readily available without
   destroying any chance of having gcl being used for small
   executables.  Suggestions as to what should be compiled in and what
   should be an autoloadable option are most welcome.

6) Had to use isfinite to distinguish between printable and non-printable 
   The existing test produced a nasty bug on powerpc where corrupted
   floats were being printed into the .data files used in
   compilation.  we will need a solaris alternative, I'm sure.  Dan? 
   Also, still waiting on the latest full build output for gcl and
   maxima on solaris.

7) Floating point (i.e. o/num_co.c) is quite a mess portability wise.
   Needs cleaning. 

8) had to change some va_arg handling for powerpc.  the existing code
   uses old style varargs.h, and is in at least the case I changed,
   not written portably.  Might need to do an overhaul of this, moving
   to stdarg.h across the board.  But the compiler uses it, so lets not
   be too hasty.

9) After testing the bfd stuff on a few more arches, can perhaps
   implement bfd faslink.    If someone wanted to test a build using
   fasldlsym.c, and to see if one could correctly save images with
   this build, I'd be most appreciative.  The FAQ says no, and that's
   why I've been sticking with the fasloading pattern Dr. Schelter had
   implemented.   But if its not necessary, dlopen is far simpler, and
   can be used for external shared libs a la faslink too.  Not sure
   about the memory implications.

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]