gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: gcl/maxima on hppa


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl/maxima on hppa
Date: 11 Aug 2002 22:51:49 -0400

Greetings!  One other piece of information on my mind on this subject
which I'd like to share before going on to other things.  gcl's
garbage collector relies on setjmp to put register contents on the C
stack, which is then walked to mark live objects.  This works on all
platforms except hppa, where gcl has currently implemented a small
assembler routine to explicitly save the registers to stack provided
courtesy of Lamont Jones.  This has cleared all apparent gc issues.

However, gcl uses setmp (and longjmp) in one other place -- in
formatting its output to the screen.  And it is here that the
remaining bugs in maxima show up -- the entire package compiles
without problems, but when running the tests, which format output to
the screen, random memory errors appear to occur after a few calls of
setjmp in the formatter, before any gc takes place.  The code example
shown below is invoked via the formatting routines.  The code itself
is taken from displa.c, maxima's display engine.

I know hppa's setjmp has been vouched for, but this seems like smoke
to me, and where there's smoke ...

Take care,


Camm Maguire <address@hidden> writes:

> reassign 146070 gcc-3.1
> reassign 151886 gcc-3.1
> thanks
> 
> Greetings, and thanks for your reply!
> 
> It appears quite clear that the difficulties in getting maxima to work
> on hppa -- the last such Debian architecture -- are gcc compiler
> related.  I'm using gcc version 3.1.1 20020703.  Here for example is a
> working gdb session through a snippet of code (the variable s_dbind
> should be being set to small_fixnum_table+1024+2) (breakpoints at
> main, line 293 and 294 -- no garbage collection at this point in
> program): 
> =============================================================================
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /fix/t2/camm/maxima-5.6b/doc/../src/saved_maxima 
> 
> Breakpoint 3, main (argc=1, argv=0xbffffa14, envp=0xbffffa1c) at main.c:131
> 131           setbuf(stdin, stdin_buf); 
> 2: ((object) VVi[11])->s = {t = 8 '\b', flag = 0 '\000', s = 0 '\000', m = 0 
> '\000', s_dbind = 0x0, 
>   s_sfdef = 0x84b4be0 <Cnil_body>, st_self = 0x90056e0 "SIZEA-ATOM", st_fillp 
> = 4, s_gfdef = 0x0, s_plist = 0x84b4be0, 
>   s_hpack = 0x84c4d68, s_stype = 2, s_mflag = 0}
> (gdb) c
> Continuing.
> GCL (GNU Common Lisp)  Version(2.5.0) Sun Aug 11 09:09:58 EDT 2002
> Licensed under GNU Library General Public License
> Contains Enhancements by W. Schelter
> Maxima 5.6 Sun Aug 11 09:09:55 EDT 2002 (with enhancements by W. Schelter).
> Licensed under the GNU Public License (see file COPYING)
> (C1) test-batch("rtest1.mac");
> 
> 
> batching #p/fix/t2/camm/maxima-5.6b/doc/rtest1.mac
> 
> Breakpoint 4, LI4 (V26=0x8ffde34) at displa.c:293
> 293           bds_bind(VV[11],small_fixnum(2));
> 2: ((object) VVi[11])->s = {t = 8 '\b', flag = 0 '\000', s = 0 '\000', m = 0 
> '\000', s_dbind = 0x0, 
>   s_sfdef = 0x84b4be0 <Cnil_body>, st_self = 0x90056e0 "SIZEA-ATOM", st_fillp 
> = 4, s_gfdef = 0x0, s_plist = 0x84b4be0, 
>   s_hpack = 0x84c4d68, s_stype = 2, s_mflag = 0}
> (gdb) c
> Continuing.
> 
> Breakpoint 5, LI4 (V26=0x8ffde34) at displa.c:294
> 294           bds_bind(VV[12],small_fixnum(0));
> 2: ((object) VVi[11])->s = {t = 8 '\b', flag = 0 '\000', s = 0 '\000', m = 0 
> '\000', s_dbind = 0x84b6d30, 
>   s_sfdef = 0x84b4be0 <Cnil_body>, st_self = 0x90056e0 "SIZEA-ATOM", st_fillp 
> = 4, s_gfdef = 0x0, s_plist = 0x84b4be0, 
>   s_hpack = 0x84c4d68, s_stype = 2, s_mflag = 0}
> (gdb) p small_fixnum_table+1024+2
> $8 = (struct fixnum_struct *) 0x84b6d30
> (gdb) 
> =============================================================================
> Here is the result on hppa (sarti):
> =============================================================================
> (gdb) r
> r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) hello
> y
> Starting program: /home/camm/maxima-5.6b/src/saved_maxima 
> 
> Breakpoint 2, main (argc=1, argv=0xbff00230, envp=0xbff00238) at main.c:131
> 131           setbuf(stdin, stdin_buf); 
> 2: ((union lispunion *) VVi[11])->s = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', 
>   m = 0 '\0', s_dbind = 0x0, s_sfdef = 0x7ee678 <Cnil_body>, 
>   st_self = 0x9d36e0 "SIZEA-ATOM", st_fillp = 4, s_gfdef = 0x0, 
>   s_plist = 0x7ee678, s_hpack = 0x7fed68, s_stype = 2, s_mflag = 0}
> (gdb) c
> c
> Continuing.
> GCL (GNU Common Lisp)  Version(2.5.0) Sun Aug 11 07:03:00 BST 2002
> Licensed under GNU Library General Public License
> Contains Enhancements by W. Schelter
> Maxima 5.6 Sun Aug 11 06:56:54 BST 2002 (with enhancements by W. Schelter).
> Licensed under the GNU Public License (see file COPYING)
> (C1) test-batch("rtest1.mac");
> test-batch("rtest1.mac");
> 
> 
> batching #p/home/camm/maxima-5.6b/doc/rtest1.mac
> 
> Breakpoint 10, LI4 (V26=0x96b5b8) at displa.c:294
> 294           bds_bind(VV[12],small_fixnum(0));
> 2: ((union lispunion *) VVi[11])->s = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', 
>   m = 0 '\0', s_dbind = 0x0, s_sfdef = 0x7ee678 <Cnil_body>, 
>   st_self = 0x9d36e0 "SIZEA-ATOM", st_fillp = 4, s_gfdef = 0x0, 
>   s_plist = 0x7ee678, s_hpack = 0x7fed68, s_stype = 2, s_mflag = 0}
> (gdb) 
> 
> Continuing.
> 
> Breakpoint 4, LI4 (V26=0x96b5b8) at displa.c:293
> 293           bds_bind(VV[11],small_fixnum(2));
> 2: ((union lispunion *) VVi[11])->s = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', 
>   m = 0 '\0', s_dbind = 0x0, s_sfdef = 0x7ee678 <Cnil_body>, 
>   st_self = 0x9d36e0 "SIZEA-ATOM", st_fillp = 4, s_gfdef = 0x0, 
>   s_plist = 0x7ee678, s_hpack = 0x7fed68, s_stype = 2, s_mflag = 0}
> (gdb) 
> 
> Continuing.
> (C2)         (FMAKUNBOUND(f), KILL(FUNCTIONS, VALUES, ARRAYS))
> 
> Breakpoint 10, LI4 (V26=0x969fcc) at displa.c:294
> 294           bds_bind(VV[12],small_fixnum(0));
> 2: ((union lispunion *) VVi[11])->s = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', 
>   m = 0 '\0', s_dbind = 0x0, s_sfdef = 0x7ee678 <Cnil_body>, 
>   st_self = 0x9d36e0 "SIZEA-ATOM", st_fillp = 4, s_gfdef = 0x0, 
>   s_plist = 0x7ee678, s_hpack = 0x7fed68, s_stype = 2, s_mflag = 0}
> (gdb) hello
> p small_fixnum_table+1024+2
> p small_fixnum_table+1024+2
> $29 = (struct fixnum_struct *) 0x7f07b4
> (gdb) hello
> =============================================================================
> Here is the preprocessed source snippet:
> =============================================================================
> 
> static char * VVi[116]={
> #define Cdata VV[115]
> (char *)(L1),
> (char *)(L2),
> (char *)(LI3),
> (char *)(LI4),
> (char *)(LI5),
> (char *)(LI6),
> (char *)(LI7),
> (char *)(LI8),
> (char *)(LI9),
> (char *)(L10),
> (char *)(LI12),
> (char *)(LI13),
> (char *)(L14),
> (char *)(L15),
> (char *)(L16)
> };
> #define VV ((object *)VVi)
> ...
> 
>         do {bds_ptr _b = bds_top+1; (_b)->bds_sym = (VV[11]); _b->bds_val = 
> (VV[11])->s.s_dbind; (VV[11])->s.s_dbind = ((object)(small_fixnum_table+1024 
> +(2))); bds_top=_b;} while (0);
>         do {bds_ptr _b = bds_top+1; (_b)->bds_sym = (VV[12]); _b->bds_val = 
> (VV[12])->s.s_dbind; (VV[12])->s.s_dbind = ((object)(small_fixnum_table+1024 
> +(0))); bds_top=_b;} while (0);
> =============================================================================
> 
> All code compiled with just -g.  Notice that lines 294 and 293 appear
> to be called out of sequence.  s_dbind does get set eventually to some
> garbage value, though I cannot tell where as gdb on hppa does not do
> watchpoints.
> 
> I'm happy to try other ideas, as I'd like to get gcl/maxima working
> here, but for now, this seems to be in the gcc camp.
> 
> Take care,
> 
> 
> Randolph Chung <address@hidden> writes:
> 
> > > This would at least seem plausible.  Can you check it out and let me
> > > know?  Especially if there is a workaround with existing compilers?
> > > (The assembly lamont sent me is in effect this -- I was referring to a
> > > workaround which might enable setjmp itself.)
> > 
> > setjmp should be fine, but there's a bug in the definition of JB_SP, so
> > if the code uses that to index into the jmpbuf then it will not work 
> > correctly. The correct offset is the 32-bit value at offset 76 from
> > the start of the jmpbuf. (jmpbuf is defined as a double array on hppa,
> > so 76/4 doesn't work, and 76/sizeof(8) is not an integer index into the
> > array)
> > 
> > randolph
> > --  
> > Randolph Chung
> > Debian GNU/Linux Developer, hppa/ia64 ports
> > http://www.tausq.org/
> > 
> > 
> 
> -- 
> Camm Maguire                                          address@hidden
> ==========================================================================
> "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
> 
> 

-- 
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]