Re: [Gcl-devel] ANSI Windows: in-package failure

[Camm Maguire]

Hi Mike!

Mike Thomas <address@hidden> writes:

> Hi Camm.
> 
> Good news again and still some bad but ANSI GCL on Windows is in a
> much better state - thanks for the help.
> 

Great!  Converging...

> >I'd suggest trying the above break sequence.  If the problem is in
> >unexec, as I suspect, look in firstfile.c and lastfile.c (I think) and
> > figure out where the beginning and ending dump addresses are. Is it
> >possible the static null_string is at an address outside this range?
> >
> Apparently so:
> 
> ===============================================
> (gdb) p &my_edata
> $1 = (char (*)[30]) 0x49ad30
> (gdb) p &my_begdata
> $2 = (char (*)[36]) 0x49acf0
> (gdb) p &my_endbss
> $3 = (char (*)[1]) 0x5aff30
> (gdb) p &my_begbss
> $4 = (char (*)[1]) 0x5aff20
> (gdb) p my_begbss_static
> $5 = 0x49c820 ""
> (gdb) p my_endbss_static
> $6 = 0x49c830 ""
> (gdb) p null_string
> $7 = 0x0
> (gdb) p &null_string
> $8 = (object *) 0x49b150
> ===============================================
> 
> Relinking with {first,last}file.o as objects rather than in the
> libraries and placing them before and after the libraries and other
> object files respectively leads us to:

OK, unfortunately, I'm going to have to revert your patch to
unixport/makefile.  We'll have to work out something else I fear, as I
need the firstfile/lastfile in the libraries so that compiler::link
will work.  Can you figure out which ar options on your system will
link the library's objects in the right order?  That would be the most
compatible solution.  Next would be adding -u options to the link
command line for the raw image to specify the link order in the
presence of conflicts, (i.e. modules explicitly named on the command
line vs. modules in the libraries), much as we do for gmp3/mul_n.o
now.  Lastly, we could make use of definitions in mingw.defs to give
mingw specific usage, but this would disable compiler::link on mingw. 

> 
> ===============================================
> (gdb) p &my_edata
> $1 = (char (*)[30]) 0x49ad40
> (gdb) p &my_begdata
> $2 = (char (*)[36]) 0x48f010
> (gdb) p &my_endbss
> $3 = (char (*)[1]) 0x5aff40
> (gdb) p &my_begbss
> $4 = (char (*)[1]) 0x49c870
> (gdb) p my_begbss_static
> $5 = 0x49b000 ""
> (gdb) p my_endbss_static
> $6 = 0x49c840 ""
> (gdb) p &null_string
> $7 = (object *) 0x49b160
> (gdb)
> 
> ===============================================
> 
> and at last:
> 
> ===============================================
> 
>  >(in-package "wrong")
> 
> Error in IN-PACKAGE [or a callee]: A package error occurred on
> "wrong": "No such
>  package".
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at IN-PACKAGE.  Type :H for Help.
>  1 (Continue)
>  2 Return to top level.
> ===============================================
> 
> Uncertain at present what the implications of this are for lisp
> compiled and loaded into a running previously saved image and then
> saved again (eg Maxima).  Presumably new static data will be outside
> the limits again.

This is not an issue, as the .data section is dumped whole.  The
firstfile/lastfile bounds apply to address ranges in the .text
section, to my understanding.  Otherwise, you'd see it clearly on
starting, loading a compiled lisp object, saving, and restarting.

> 
> Having said that, Maxima CVS compiles and passes "make check" with
> this new CVS ANSI build on Windows subject to those defsystem patches
> discussed the other day.
> 

Great!

> I'll clean up and check in the changes to the stable branch when I
> have a spare moment hopefully tomorrow after checking with builds of
> various things.  My feeling is that once these changes are all into
> the stable tree, we must be pretty close to a new release candidate.
> 

Good.  I'll look over your other stuff, but we have a bit of work to
do on unixport/makefile.  It might be best to have a bit more
discussion when changing the core files used by all platforms.  Then
again, I certainly don't want to be a bottleneck to GCL development,
and your efforts here are critical and much appreciated.

> The ANSI test still fails:
> 
> ===============================================
>  KEYWORDP.9 KEYWORDP.10 KEYWORDP.12 KEYWORDP.ORDER.1 KEYWORDP.ERROR.1
>  KEYWORDP.ERROR.2 MAKE-SYMBOL.1 MAKE-SYMBOL.2 MAKE-SYMBOL.3
>  MAKE-SYMBOL.4 MAKE-SYMBOL.5 MAKE-SYMBOL.6 MAKE-SYMBOL.7 MAKE-SYMBOL.8
>  MAKE-SYMBOL.9 MAKE-SYMBOL.10
> Error in DO-TESTS [or a callee]: The GO tag NIL is not established.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER.
>  1 (Continue) Retry loading file "gclload.lsp".
>  2 Return to top level.
> dbl:CL-TEST>>>
> ===============================================
> 
> or under gdb:
> 
> ===============================================
> 
>  MAKE-SYMBOL.4 MAKE-SYMBOL.5 MAKE-SYMBOL.6 MAKE-SYMBOL.7 MAKE-SYMBOL.8
>  MAKE-SYMBOL.9 MAKE-SYMBOL.10
> Program received signal SIGSEGV, Segmentation fault.
> 0x7800bd65 in abnormal_termination () from C:\WINNT\system32\msvcrt.dll
> (gdb) bt
> #0  0x7800bd65 in abnormal_termination () from C:\WINNT\system32\msvcrt.dll
> #1  0x0022ffe0 in ?? ()
> #2  0x006554b8 in frame_stack ()
> #3  0x7801e742 in longjmpex () from C:\WINNT\system32\msvcrt.dll
> (gdb)
> ===============================================
> 
> Seems that there may be a problem with the way longjmp is used on Windows.
> 

OK, could you possibly isolate which test is causing this, i.e. with
explicit lisp commands if possible?  I've looked in make-symbol.10 and
make-symbol.11, and cannot see where the tagbody is (or the
catch/throw).  It might be helpful here to run the above with
(si::use-fast-links nil).

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> _______________________________________________
> 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