Re: [Gcl-devel] Segmentaton fault

[Camm Maguire]

Greetings!

1) I've figured out how to trap C stack overflows more gracefully by
   looking at older GCL code.  Basically one needs to define
   SETUP_SIG_STACK in linux.h to use sigaltstack to provide an
   alternate stack to process the segmentation signal handler.  I've
   done this, have tested, and it works well for me.  One can continue
   from this condition, e.g. by quitting to the top level, and
   restoring the stack pointer to its original value.

2) Thank you for bringing to my attention 'sibling call'
   optimizations, which are apparently newly implemented in gcc.  I've
   been playing with some hand edited C code originally corresponding
   to your lisp example, and have been unable to get gcc to replace
   the calls by jumps.  Perhaps there is an example somewhere you can
   share?  There are several options available in supporting these,
   but all to my understanding will require modification of the lisp
   compiler.  We call C code via a pointer, which can be redirected
   via (si::use-fast-links [t|nil]) to either make the call directly
   or to proceed via the lisp stack to facilitate debugging.  I'm
   pretty sure gcc won't optimize sibling calls when written this
   way.  One option is to provide a compiler switch which would write
   the calls in some as yet determined alternate way which would be
   optimizable and non-lisp debuggable.  Another would be to try to
   optimize the calls at the lisp level, as simple single function
   tail recursive calls are now done.  The problem, of course is that
   one needs both entry points to the functions themselves from outside
   the sibling pair as well as internal entry points for use by the
   pair itself..  Just checked that C compiled goto labels cannot
   cross function boundaries.

3) Am going away until next Wednesday.   will try to commit the
   sigaltstack stuff then.

Take care,

Eric Merritt <address@hidden> writes:

> Camm,
> 
>  The core problem in this instance (besides the
> problem you described below) is that these mutually
> recursive functions are not optimized as tail calls. I
> did a little research into tail calls in gcc and it
> looks like they are supported (with a few issues of
> course, although gcc 3.4 is supposed to make these
> types of calls much better). Have you guys aready
> looked into this? These optimizations are very much
> gcc specific, but I get the feeling that you gcl is
> already tightly coupled to gcc already. 
> 
> Just curious, thanks for all the effort with gcl.
> Eric
> 
> 
> 
> --- Camm Maguire <address@hidden> wrote:
> > Greetings!  What is happening here is that the C
> > stack is overflowing,
> > raising a sigsegv, triggering the
> > segmentation_catcher handler which
> > has rudimentary code reporting C stack overflow
> > conditions, but being
> > unable to call it as there is no more C stack space.
> >  I just tried
> > mprotecting the last page of C stack PROT_READ or
> > some such --
> > mprotect won't work on the stack.  If you know of a
> > way to raise the
> > sigsegv in advance of being absolutely out of C
> > stack space, which
> > would allow the error handler to run, I'd be happy
> > to consider
> > implementing it.
> > 
> > Take care,
> > 
> > Eric Merritt <address@hidden> writes:
> > 
> > > Camm,
> > > 
> > >  Here is the backtrace you requested.
> > > 
> > >
> >
> -----------------------------------------------------
> > > #0  0x40189f0f in tcgetattr () from /lib/libc.so.6
> > > #1  0x40185b96 in isatty () from /lib/libc.so.6
> > > #2  0x080642ed in rl_putc_em (c=32, f=0x401dfda0)
> > at
> > > gcl_readline.d:230
> > > #3  0x08052b5a in writec_stream (c=32,
> > strm=0x8531558)
> > > at file.d:933
> > > #4  0x0807df1e in writec_PRINTstream (c=32) at
> > > print.d:223
> > > #5  0x0807f553 in write_object (x=0x844dd20,
> > level=0)
> > > at print.d:719
> > > #6  0x0808310b in princ (obj=0x844dd20,
> > > strm=0x8531510) at print.d:1891
> > > #7  0x080832e3 in print (obj=0x8a5ec84,
> > > strm=0x8514020) at print.d:1948
> > > #8  0x0804ac57 in L1 () at test.c:14
> > > #9  0x0804acbc in L2 () at test.c:301
> > > #10 0x0804ac6b in L1 () at test.c:16
> > > #11 0x0804acbc in L2 () at test.c:30
> > > #12 0x0804ac6b in L1 () at test.c:16
> > > #13 0x0804acbc in L2 () at test.c:30
> > > #14 0x0804ac6b in L1 () at test.c:16
> > > #15 0x0804acbc in L2 () at test.c:30
> > > #16 0x0804ac6b in L1 () at test.c:16
> > > #17 0x0804acbc in L2 () at test.c:30
> > > -------------------------------------------------
> > > 
> > > This goes on for atleast another 65000+ lines with
> > no change
> > > 
> > > 
> > >   
> > >           
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Photos: High-quality 4x6 digital prints for
> > 25¢
> > > http://photos.yahoo.com/ph/print_splash
> > > 
> > > 
> > > 
> > 
> > -- 
> > Camm Maguire                                                address@hidden
> >
> ==========================================================================
> > "The earth is but one country, and mankind its
> > citizens."  --  Baha'u'llah
> 
> 
> 
>       
>               
> __________________________________
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25¢
> http://photos.yahoo.com/ph/print_splash
> 
> 
> 

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