Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS

[Camm Maguire]

Greetings!

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

> Hi Camm!
> 
> I'm sorry for long silence but my main job rendered me
> incapable of doing anything constructive to GCL/Maxima
> for whole month.
> 
> I decided not to apply any (build-symbol-table) patches
> to GCL CVS since I'm not quite sure that we need this
> symbol tables.  In any case we can easily do this
> as soon as we realize their necessity.  The only thing
> I've noticed is that if we build usual saved_gcl without
> (build-symbol-table) before (save-system) then
> later saved_pcl build fails with obscure error message.
> 

Good call, IMHO.  I've put the build_symbol_table in by hand in
init_init, which is called at the beginning of the execution of any
"raw" image.  This seems to be the place producing the most compact
symbol table.  Calling it again via lisp later on will surely bloat
the image unnecessarily.  We may want to remove the lisp handle all
together.  For any image will be unable to load objects without the
symbol table as you point out -- its a required part of the image
initialization.

> I've almost finished editing gcl.texi to comply with
> modern texinfo.  It is turned out quite straightforward
> but long and routine work.
> 

***Thank you**!!

Take care,

> 
> Camm Maguire:
> > Greetings!
> > 
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> > 
> > 
> >>Camm Maguire ÐÉÛÅÔ:
> >>
> >>>Hi Vadim!  Your patch looks fine.
> >>>
> >>>1) Is there anything different about the resulting build with or
> >>>   without the initform, short of the 'building...' message, as far as
> >>>   you can tell?
> >>
> >>I don't see any difference except new images are bigger (about 1Mb).
> >>BTW, how can I see that symbol table is _really_ present in
> >>saved_<something>?  Do I need gdb?
> >>
> > 
> > 
> > This is the easiest way.  Just gdb saved_..., and do 'l main.c:1'
> > 
> > 
> >>>2) I'd appreciate if we could not modify the default linux.{h,defs}
> >>>   until discussing a bit further.
> >>>3) You can commit the makefile patches if you want, to facilitate
> >>>   experimentation. 
> >>
> >>Maybe we should add some new configure option.
> >>Something like --without-symbol-table.
> >>Without this option all images are build with or
> >>without symbol table according to appropriate .defs.
> >>With --without-symbol-table no symbol table
> >>in any saved_<...>?
> >>
> > 
> > 
> > Well, keep in mind that the raw_gcl symbol table must always be built
> > if you want to load binary objects!  Or maybe I am misunderstanding
> > you.  There are two issues -- gcl's symbol table for object
> > loading/relocation, and a set of *debugging symbols* in the final
> > image, conventionally kept in .stabs sections I think.  The idea of a
> > configure option is not bad though.  What it would have to do to keep
> > gdb symbols, however, is to alter the makefiles to use ld for the final
> > link at each image production stage.  Rebuilding the
> > relocation/loading symbol table could be done as in your patch, but is
> > likely unecessary, and is now confirmed by your test to bloat the
> > image.  The compiler just won't spit out symbols that can't be found
> > int the compact raw_gcl image.  We should probably even make certain
> > new modules, like destructuring-bind and loop, external to this symbol
> > table build, perhaps by making them 'load on demand' objects like
> > readline.o.  
> > 
> > Take care,
> > 
> > 
> >>>thanks!
> >>>
> >>>"Vadim V. Zhytnikov" <address@hidden> writes:
> >>>
> >>>
> >>>
> >>>>This is a multi-part message in MIME format.
> >>>>--------------080605030101030203060402
> >>>>Content-Type: text/plain; charset=KOI8-R; format=flowed
> >>>>Content-Transfer-Encoding: 8bit
> >>>>
> >>>>Camm Maguire ÐÉÛÅÔ:
> >>>>
> >>>>
> >>>>>If it wouldn't be too much trouble, could you post the diff first?  
> >>>>>
> >>>>>My original concern was in running ansi images in gdb -- and the
> >>>>>answer there seems to be using the system ld for the final link, as
> >>>>>even with a working native reloc code, we don't import the .stabs
> >>>>>debugging section of the objects, so those pieces of code effectively
> >>>>>become black boxes to gdb.  We could change this in the future, or
> >>>>>provide an option to do so, but for now only developers should be
> >>>>>interested and the easiest thing is to provide a make target which
> >>>>>uses ld.  So the symbol table building here is not an issue.
> >>>>>
> >>>>>Beyond this, regarding the compile time/runtime initialization -- this
> >>>>>again is apparently not a problem, and I think I now know why.  The
> >>>>>lisp compiler is very careful not to compile in named references to
> >>>>>any functions that aren't available in raw_gcl.  All other function
> >>>>>links are arbitrarily named and connected to the proper function at
> >>>>>load time.  So in short, the symbol table built when initializing
> >>>>>raw_gcl should suffice, and it apparently does or else all hell would
> >>>>>break loose when loading pcl objects as part of the ansi build.  
> >>>>>
> >>>>>So in sum, I don't think we need to build the symbol table again -- in
> >>>>>fact, it would just be a gratuitous waste of memory space, adding in
> >>>>>symbols which the loader would never need.  But I could be wrong, and
> >>>>>would like to see your diff in any case.
> >>>>>
> >>>>>Take care,
> >>>>
> >>>>
> >>>>Actually patch is very simple (see attachment):
> >>>>----------------------------------------------------------------
> >>>>diff -uNr gcl-2.5.0-orig/clcs/makefile gcl-2.5.0/clcs/makefile
> >>>>--- gcl-2.5.0-orig/clcs/makefile  2002-06-28 08:42:52 +0400
> >>>>+++ gcl-2.5.0/clcs/makefile       2002-08-17 15:58:23 +0400
> >>>>@@ -1,11 +1,13 @@
> >>>>
> >>>>+-include ../makedefs
> >>>>+
> >>>> #LISP=../pcl/saved_gcl_pcl
> >>>>
> >>>> compile: ${LISP}
> >>>>  echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> >>>>:compile)' | ${LISP}
> >>>>
> >>>> saved_full_gcl: ${LISP}
> >>>>- 
> >>>>echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> >>>>:compiled)(system::save-system "saved_full_gcl")' | ${LISP}
> >>>>+ 
> >>>>echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> >>>>:compiled)$(INITFORM)(system::save-system "saved_full_gcl")' | ${LISP}
> >>>>
> >>>> -include ../makedefs
> >>>>
> >>>>diff -uNr gcl-2.5.0-orig/pcl/makefile gcl-2.5.0/pcl/makefile
> >>>>--- gcl-2.5.0-orig/pcl/makefile   2002-08-06 19:43:42 +0400
> >>>>+++ gcl-2.5.0/pcl/makefile        2002-08-17 15:58:59 +0400
> >>>>@@ -1,5 +1,7 @@
> >>>> # makefile for making pcl -- W. Schelter.
> >>>>
> >>>>+-include ../makedefs
> >>>>+
> >>>> #  Directions:
> >>>> # make -f makefile.gcl compile
> >>>> # make -f makefile.gcl saved_pcl
> >>>>@@ -18,7 +20,7 @@
> >>>>  echo ${SETUP} '(pcl::compile-pcl)' | $(LISP)
> >>>>
> >>>> saved_gcl_pcl:
> >>>>- 
> >>>>echo ${SETUP} '(pcl::load-pcl)(si::save-system "saved_gcl_pcl")' | $(LISP)
> >>>>+ 
> >>>>echo ${SETUP} '(pcl::load-pcl)$(INITFORM)(si::save-system 
> >>>>"saved_gcl_pcl")' | $(LISP)
> >>>>
> >>>> clean:
> >>>>  rm -f *.o *.fn *.exe *.dll saved_gcl_pcl
> >>>>-------------------------------------------------------------------
> >>>>
> >>>>We just insert $(INITFORM) right before (si:save-system ...).
> >>>>The value of $(INITFORM) is defined in h/<arch>.defs and may
> >>>>be either  equal to (si::build-symbol-table) or empty.
> >>>>But maybe we should make $(INITFORM) subject to new configure
> >>>>option, say --enable-symbol-table ?
> >>>>
> >>>>Best wishes,
> >>>>
> 
> -- 
>       Vadim V. Zhytnikov
> 
>        <address@hidden>
>       <address@hidden>
>       <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