[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
on.
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
floats.
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
- [Gcl-devel] Pure bfd checked in,
Camm Maguire <=