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

[Mike Thomas]

Hi Camm.

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

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

===============================================
(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.

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.

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.

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.


Cheers

Mike Thomas.