Re: [Gcl-devel] Cygwin change

[Camm Maguire]

Greetings!

Dan Stanger <address@hidden> writes:

> I would be interested in seeing the result of my  test program on each of 
> these
> systems.
> Then we could maybe see if the problem is related to stack, text and heap
> placement.

OK, I've included the output from ppc, m68k, i386 Linux, and sparc
below.
=============================================================================
ppc
=============================================================================
./foo
address of i was 7ffffd68 e was 1001082c
macro of i was 1 e was
0
address of i was 7ffffd48
address of malloc was 100108e0
=============================================================================
m68k
=============================================================================
address of i was effffd30 e was 800026fc
macro of i was 1 e was
0
address of i was effffd24
address of malloc was 80002708
=============================================================================
i386
=============================================================================
address of i was bffff758 e was 80496c0
macro of i was 1 e was
0
address of i was bffff738
address of malloc was 80496d0
=============================================================================
sparc
=============================================================================
address of i was effffcf4 e was 21b58
macro of i was 1 e was
0
address of i was effffc84
address of malloc was 21b68
=============================================================================

As I've alluded to earlier, I'm beginning to think that a simple
setting of DBEGIN/NULL_OR_ON_C_STACK is not going to significantly
help us with porting.  These certainly must be done correctly, its
just that I cannot believe that all the settings except for i386 Linux
are wrong.  I can list what I'm using on each arch, but it would
appear that these variables are set correctly at least in most cases.
Further evidence in this regard is that changing these settings
doesn't noticeably alter the maxima compile failure -- always stops in
exactly the same place.  If the settings are wrong, they are certainly
not very wrong, and it would take a *very* large stack to get to a
location which the NULL... macro would flip over.

Among the other things that make me think this way is the m68k patch I
wrote about earlier.  It could be that the C compiler is simply
miscompiling these function links without adequate prototypes.  This
would imply some difficulty with the loading/linking, but here again,
while possible, I think this is less likely than a gc bug.  The reason
is that in most cases, the linking problems show up before a
saved_gcl gets produced at all -- raw_gcl gives it a good workout.

We have all the signs of a gc error, but one perhaps not related to
the position of the C stack.  I've been tracing a few key function
jumps on my fastest failing machine (ppc), and found a place where the
function address was 0x8000000 for a cf_name "LET".  I often see
maxima messages complaining of dots appearing illegally triggered by
let.  It is also interesting that the letmac.o that maxima uses to
redefine gcl's let uses a kludge to suppress warnings, as indicated by
the comments at the top of the file.  Haven't yet found exactly where
this corruption takes place, but it does follow the first gc in the
maxima build.  I've been trying to reset some of the
holepage/etc. parameters in object.h, and invoke init_tm from
init_alloc to give higher maxpages to the various types before gc will
trigger, in attempts to see that if gc can be delayed past my error
point, will the error disappear?

One might also be interested in investigating the DEGUG macro and
debug variable in gbc.c.  I've set these in the code, and one gets a
nice summary of the action of each gc.  One also has the (room) list
function to report gc issues.  But alas, so far, I cannot pinpoint
what is happening.

I do know that if you are in gdb, you must set breakpoints before the
bad function jumps if you want to keep any debugging information.
I.e., at eval.c:159, at c_apply_n, etc.  There are many of these, and
I'm sure I haven't found all of them yet.  



> I think compiling with -g is a good idea also, as well as fixing warnings.  I 
> dont
> think
> changing garbage collection methods is a good idea, as fast lisp garbage
> collection may be
> different then the Boehm method.  I think we should look at the memory layout
> issue more carefully, there are probably assumptions about it that may not be
> true.

You are right at least in one key aspect here -- WFS et. al. managed
to implement an *exact* gc for gcl, which should be better than a
conservative generic one.  I.e., all possible pointer locations are
examined tracing down the lisp tree from its roots, as opposed to
sequentially walking the heap and looking for everything that appears
to be a pointer in the right range.  On the other hand, the generic
Boehm collector is much more likely to be free of errors.  As our
experience with gcl grows, we can begin to weigh the tradeoff here.
In any case, it won't be so easy, at least not trivial, to implement
libgc here -- much mm uses (s)brk instead of malloc, so one can't
simply get by with malloc ->GC_MALLOC, or whatever.

> 
> If you can tell me how to run the tests with gdb, from the makefile or get a 
> input
> file
> for gcl to compile maxima, that would be helpful.  I know how to run gdb, but 
> I am
> 
> not sure which lisp commands to build maxima to use.

If you have the maxima distribution, go to the src directory, and

gdb (gcl-dir)/unixport/saved_gcl

The initial 'make command from the base maxima tree should create a
file 'foo' in src which is lisp input to gcl.  I've winowed mine down
a bit to this for testing:

(load "sysdef.lisp") (load "/home/camm/gcl-2.5.0/lsp/sys-proclaim.lisp") (load 
"sys-proclaim.lisp") (make::make :maxima-macros :compile t)



> Also, I have another request.  Can you modify the makefile so it doesnt ring 
> the
> terminal bell?

Will do!

> I tried to remove the ^g from the file, but the makefile broke.
> Also, are there docs on gcc on these platforms, regarding placement of stack, 
> heap
> and other memory?

Not that I know of, alas.  ELF_TEXT_BASE is defined, but as for other
sections, I'm not sure.

Take care,

> Dan
> 
> Camm Maguire wrote:
> 
> > Greetings, and thanks for trying this out.
> >
> > OK, in sum of the progress thus far, we can get apparently successful
> > builds on:
> >
> > ix86 Linux (all flavors), m68k Linux, arm Linux, ppc Linux, Win NT.
> >
> > All but the first, however, fail to successfully build maxima, and
> > from what you describe below coupled with my own experience, all are
> > showing similar errors.
> >
> > I have two hunches -- garbage collecting errors, or residual problems
> > with the 'fasloading'.  The latter I feel is less likely, as this will
> > vary on each of the archs, and the fact that the behavior is similar
> > would seem to indicate something else.
> >
> > We have several possible lines of attack:
> >
> > 1) Compile with -g, place breaks at fasload, call_init, and do_init,
> >    locate the  place where memory is apparently corrupted, set a watch
> >    at that address, and see where it first happens.  Try to see if
> >    there is a way to eliminate calling GBC, or at least defer it, for
> >    the purposes of testing.
> > 2) Forge ahead with a test build with an external gc, such as the
> >    Boehm gc.
> > 3) Start tracking down and fixing all the warnings  with -Wall.
> > 4) See if it is at all possible to get a build which starts its text
> >    section at the same location as on the working ix86 case, 0x800000
> >    (I think).  (i.e. -Ttext arg to ld).
> >
> > The only thing in common that I can see in these cases is that each
> > has a different base load address.
> >
> > Ideas?
> >
> > I'll be trying a mixture of these, probably on ppc first.  My guess is
> > that the resolution of any one of these issues will greatly facilitate
> > the rest.
> >
> > Take care,
> >
> > "Billinghurst, David (CRTS)" <address@hidden> writes:
> >
> > > I have just build gcl on cygwin with
> > >
> > > #define DBEGIN 0x1a000000
> > > #define NULL_OR_ON_C_STACK(y) (((void *)(y)) < ((void *)(0x400000)))
> > >
> > > then tried to compile maxima with it.  It works for some files, but not
> > > for others as I get errors
> > >
> > > Error: Caught fatal error [memory may be damaged]
> > >
> > >
> > > -----Original Message-----
> > > From: Camm Maguire [mailto:address@hidden
> > > Sent: Monday, 14 January 2002 9:30=20
> > > To: address@hidden
> > > Cc: address@hidden
> > > Subject: Re: [Gcl-devel] Cygwin change
> > >
> > >
> > > Hello again!  Forgot to ask, is this with the value of DBEGIN I sent
> > > you, or the original one?  Could you please report its value here to
> > > be sure?
> > >
> > > Thanks!
> > >
> > > Dan Stanger <address@hidden> writes:
> > >
> > > > There was really only 1 change, that is to change the definition of
> > > > NULL_OR_ON_C_STACK to:
> > > >=20
> > > > #define NULL_OR_ON_C_STACK(y) (((void *)(y)) < ((void *)0x400000))
> > > >=20
> > > > I think this is ok as 0 gets checked by this case also.  You also have
> > > > to put the file
> > > > unexnt.c back into the normal cvs.
> > > > Dan
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > Gcl-devel mailing list
> > > > address@hidden
> > > > http://mail.gnu.org/mailman/listinfo/gcl-devel
> > > >=20
> > > >=20
> > >
> > > --=20
> > > Camm Maguire
> > > address@hidden
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > =3D=3D
> > > "The earth is but one country, and mankind its citizens."  --
> > > Baha'u'llah
> > >
> > > _______________________________________________
> > > Gcl-devel mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/gcl-devel
> > >
> > > _______________________________________________
> > > 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
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah