Re: [Gcl-devel] Windows - Instability in universe.lsp

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> | Greetings!
> |
> | 1) Please excuse any possible dropped email  on my part -- we've had
> |    system problems.
> 
> No worries.
> 
> | 2) Please check out the configure patch skipping the sbrk test when
> |    there is no sbrk.  Aurelien, it would be helpful if you could do
> |    the same.
> 
> It worked here, thank you, apart from a spelling mistake:
> 
> checking for sbrk... no: WARNING you must beable to emulate sbrk: as on
> mingw or macosx
> 

Thanks!  Will fix.

> | 3) Regarding gcc optimization on Windows and test results thereof --
> |    this is encouraging!  While it is not impossible that we still have
> |    a problem in GCL, this increases the likelihood in my mind that gcc
> |    on mingw is the issue.  Mike, do you know what differs if anything
> |    between mingw gcc and stock gcc?
> 
> Apart from the replacement of Unixy things like fork() which really only
> affect the way the compiler runs rather than the code it generates I
> couldn't say.
> 
> I believe that the Cygwin and MinGW32 code generators, however, are the
> same.  Likewise that only things which allow MS Visual C++ compatibility are
> different from the Linux i386 version, but I can't really be sure.  An
> example of the latter, by the way is the -mms-bitfields switch which I use
> to ensure equivalent handling of bitfields to MSVC++ to allow GCL libraries
> to be compatible in the event that someone decides to build a GCL DLL.
> 
> I'll look further into this but I suspect that it will be difficult to get
> much specific information without examining the gcc source, which I am
> reluctant to do.
> 
> I did quite a lot of fooling around with compiler options a year or two ago
> when I first started working with GCL and again when the ANSI build problem
> first showed up, but I'll aim to try some more soon as the gcc version has
> moved on since then and we are looking at different code.
> 

Don't suppose it would be possible to check just the cygwin compiler
without doing a lot of work?  I.e. are the dll's used inextricably
tied up with the compiler used?

> 
> | Diff finished at Tue Mar 30 19:35:26
> |
> |    Perhaps you can report the output of this test and/or investigate
> |    what is going on?  Perhaps you can also run with --enable-debug or
> |    equivalently only -O0?
> 
> I'm pleased to report that with the stable source updated this morning there
> are now only 305 errors and that the particular test you mentioned passes.
> I'll try again this evening with my other computer and see how we go there
> but I'm expecting everything to match.
> 

Great!  There are quite a few compiler options, of course, which are
enabled in groups by the -O options.  Pinning down which option causes
the 306th test to fail might be useful at some point.  Likewise if the
306th test can be made to fail in isolation.  I.e. (load
"gclload1.lsp")(load "file containing failing 306th
test.lsp")(rt:do-tests).  If so, then we can (disassemble...) the
function definition for the failing test and try to get a simple test
case.  

In general, though, I'm quite happy to proceed to 2.6.2 with -O0 on
mingw if it continues to prove stable, i.e. fixes both ansi issues,
and both maxima issues, particularly compiling maxima with the latest
gcc.  For some as yet only partially understood reason, we are using
-O0 on hppa too.


> 
> | 4) Re random tester -- I will endeavor to backport the minimal set of
> |    files to run this against stable, as I feel it is an important
> |    measure of GCL quality.  Will followup with Paul about this
> |    separately.
> 
> This falls in the category of thinking too hard close to the deadline - I
> might be too scared to run the random tester!
> 

Fear not -- my guess is that you'll be in good shape with -O0.

> 
> | 5) Re any possible further debugging efforts -- I think we should
> |    stick with stable until release
> 
> Done.
> 
> 
> 
> | 6) Re appearance of C stack in gdb as a sign of error -- this can
> |    indicate an error, or it can indicate an issue with gdb, so it is
> |    not a completely reliable test.  This having been said, I'm
> |    including below the results of my gdb session on (load
> |    "gclload.lsp") mirroring yours, and my gdb trace looks a lot
> |    better.  I think the key is not so much the output of bt, but
> |    rather:
> |
> | Run till exit from #0  0x0041f7b0 in Leval () at eval.c:1171
> | Warning:
> | Cannot insert breakpoint 0.
> | Error accessing memory address 0x104bfe66: Input/output error.
> |
> |    This is an address in the 'hole' or relocatable area on your
> |    system, and so should never appear as a stack address.
> 
> Pardon my lack of understanding but when you say "'hole' or relocatable
> area" do you mean that those terms are synonymous or that they are two
> alternative memory location categories into which the address might be
> falling?

Here's a rough sketch of the memory layout:

dbegin -- heap_end
hole
relocatable area
core_end

All compiled lisp functions should be allocated as contiguous pages in
the heap, i.e. before heap_end.


> 
> 
> |  This could
> |    either indicate a problem, or a gdb corruption.  Perhaps you could
> |    run with b *0x104bfe66 and see if the instruction pointer ever gets
> |    to this address?
> 
> 
> OK thanks; I hadn't realised before that you could feed a function address
> to "break".  Handy to know and will try this out.
> 

Great!

> 
> |
> | 7) Re debugging deep into a lisp job -- the way to do this is to take
> |    the test showing the first sign of trouble, and inserting (si::break
> |    "foo") in its defining lisp code (found in the appropriate .lsp
> |    file under ansi-tests).  One can then run a lisp debugging session
> |    on top of a gdb debugging session, as Dr. Schleter used to point
> |    out.
> 
> Another thing I had never heard of which sounds very helpful.
> 
> I was imagining (and in fact recently implemented but not yet checked in)
> (say three) break commands which were essentially do nothing special forms
> implemented in C land.  You can then set gdb breaks on one or more of those
> forms' underlying C function after inserting them at different levels in
> nested iterative lisp code so that you could break at a certain stage at a
> higher level and then if necessary set a gdb break on the form already
> present in the lower level of the iteration when you felt the need to refine
> your level of breaking.
> 
> |
> | 8) Re deadline of a fortnight -- sounds good to me.  Hopefully we'll be
> |    ready well in advance of this.
> 
> Great.
> 
> I'll let you know how things progress.
> 

Thanks!  Please keep us posted.

Take care,

> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 
> 

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