Greetings! I've taken on the task of maintaining GCL. (The project
is currently setup at savannah.gnu.org, for those interested.) I'd
like to get the code working on as many platforms as possible,
especially, the Linux architectures supported by Debian. The only
really non-portable piece, from what I can so far tell, is this bit
about "fasloading".
I don't know the history behind the decision to use this method in the
Lisp community, but I am aware that this is a subject which has
received some controversial discussion in the context of the future
and evolution of the language.
My current strategy is to keep this basic design, but use the bfd
library to try to get the elf relocations working portably. But over
the long term, I do wonder why it wouldn't be simpler just to compile
objects as PIC code, and link them in as shared objects. One will
have to decide how to handle the "lisp vector" traditionally appended
at the end of the Elf file, but this should not be insuperable.
1) Am I overlooking something, i.e. is there a really good reason for
the existing "fasloading" mechanism which would necessitate keeping
it indefinitely?
2) In your experience working with Lisp (of which I have basically
none), do you have opinions/suggestions on how object loading
should best be accomplished?
Thanks!
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> wrote in message news:<·················@intech19.enhanced.com>...
> Greetings! I've taken on the task of maintaining GCL. (The project
> is currently setup at savannah.gnu.org, for those interested.)
I'm very pleased to hear this! Best wishes!
> But over
> the long term, I do wonder why it wouldn't be simpler just to compile
> objects as PIC code, and link them in as shared objects.
I don't think I understand. Currently GCL compiles to C
executables. Are you suggesting changing this?
> 1) Am I overlooking something, i.e. is there a really good reason for
> the existing "fasloading" mechanism which would necessitate keeping
> it indefinitely?
What do you mean by "fasloading"? Do you mean the current
practice of dynamically linking the .o files with the image?
dave
>>>>> "TheBean" == TheBean <··········@yahoo.com> writes:
>> But over the long term, I do wonder why it wouldn't be simpler
>> just to compile objects as PIC code, and link them in as shared
>> objects.
TheBean> I don't think I understand. Currently GCL compiles to
TheBean> C executables. Are you suggesting changing this?
As I understand it, GCL does compile to C, but it doesn't use the
dynamic linker. That is to say, GCL doesn't use the operating
system's dynamic linker to load compiled Lisp files. Camm wants to
know if there is a reason for this beyond the historical.
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
"Little grey men are coming our way (tastes just like chicken, they say)."
- Clutch
"Matthew X. Economou" <········@irtnog.org> wrote in message news:<···············@eco-fs1.irtnog.org>...
> >>>>> "TheBean" == TheBean <··········@yahoo.com> writes:
>
> >> But over the long term, I do wonder why it wouldn't be simpler
> >> just to compile objects as PIC code, and link them in as shared
> >> objects.
>
> TheBean> I don't think I understand. Currently GCL compiles to
> TheBean> C executables. Are you suggesting changing this?
>
> As I understand it, GCL does compile to C, but it doesn't use the
> dynamic linker. That is to say, GCL doesn't use the operating
> system's dynamic linker to load compiled Lisp files. Camm wants to
> know if there is a reason for this beyond the historical.
I see .. PIC: Position Independent Code .. as in gcc -fPIC. Sorry
about the confusion.
I can certainly see how this would be better from a maintenance and
porting point of view.
dave
In article <···············@eco-fs1.irtnog.org>,
Matthew X. Economou <········@irtnog.org> wrote:
>>>>>> "TheBean" == TheBean <··········@yahoo.com> writes:
>
> >> But over the long term, I do wonder why it wouldn't be simpler
> >> just to compile objects as PIC code, and link them in as shared
> >> objects.
>
> TheBean> I don't think I understand. Currently GCL compiles to
> TheBean> C executables. Are you suggesting changing this?
>
>As I understand it, GCL does compile to C, but it doesn't use the
>dynamic linker. That is to say, GCL doesn't use the operating
>system's dynamic linker to load compiled Lisp files. Camm wants to
>know if there is a reason for this beyond the historical.
Portability seems the most likely reason. That's one of the reasons why it
compiles to C in the first place. I'm not sure how common the dlopen()
family of functions is these days, but when GCL was first written (I think
it was Kyoto CL in those days) I'm pretty sure it was only available on
SunOS. Or it could even predate that.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <···············@eco-fs1.irtnog.org>,
> Matthew X. Economou <········@irtnog.org> wrote:
> >>>>>> "TheBean" == TheBean <··········@yahoo.com> writes:
> >
> > >> But over the long term, I do wonder why it wouldn't be simpler
> > >> just to compile objects as PIC code, and link them in as shared
> > >> objects.
> >
> > TheBean> I don't think I understand. Currently GCL compiles to
> > TheBean> C executables. Are you suggesting changing this?
> >
> >As I understand it, GCL does compile to C, but it doesn't use the
> >dynamic linker. That is to say, GCL doesn't use the operating
> >system's dynamic linker to load compiled Lisp files. Camm wants to
> >know if there is a reason for this beyond the historical.
>
> Portability seems the most likely reason. That's one of the reasons why it
> compiles to C in the first place. I'm not sure how common the dlopen()
> family of functions is these days, but when GCL was first written (I think
> it was Kyoto CL in those days) I'm pretty sure it was only available on
> SunOS. Or it could even predate that.
Nowadays dlopen() et al is as common as mmap() et al (i.e. names and
functionalities are slightly different, but they perform similar tasks).
Most unixen have dlopen() specifically, with the exception of the 32-bit
HP-UX shl_load() and the MacOSX NSLinkModule(). Windows systems have
LoadLibrary(). The 64-bit protocol for the HP deprecated the shl_*
functions and went with a standard dlopen() functionality.
The GCL loading question is a similar issue to what we had in historic
Allegro CL foreign-function loading. Before we went to a shared-library
interface, foreign code had to be .o files, and we used the old -A option
of ld() to link those .o's against the running image and read the result
into memory. It was a real pain to deal with; we had to predict where the
next sbrk() allocation would be, but if malloc was called at an
inopportune time (i.e. after we had done the "ld -A ..." to find out how
much to allocate, but before actually doing that allocation), that sbrk
location would change. Now, in versions of Allegro CL since 4.2 or
thereabouts, foreign code for dynamic loading is required to be in
shared libraries (either in .so, .sl, .dll, or .dylb formats) and the
dlopen equivalents make the task of loading much easier and more portable,
since "ld -A ..." usually was frought with bugs depending on the
operating system. I don't know what to recommend for GCL; using
shared-libraries would definitely be easier and more portable, but it
will also slow down the function linkage quite a bit.
SunOS5/Solaris2 has always had dlopen capability, and SunOS4/Solaris1
had the entry points but they really didn't work the way we now expect
dlopen/dlsym to work nowadays. I tried to backport our shared-library
loading facility to our SunOS4/Solaris1 port because so many of our
customers wished that they could keep their more familiar system, but I
found that the dlopen simply didn't work to the extent that we were
using it. I don't now remember what the errors were.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)