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

[Mike Thomas]

Hi Camm.

> #3  0x080a4f42 in Icall_continue_error_handler (error_name=0x853b678, 
>    error_format_string=0x8a70f90, nfmt_args=2) at error.c:158
> (gdb) p (((long)(0) + (4 -1)) & ~(4 -1))
> $25 = 0
> (gdb) p null_string
> $26 = 0x852fcf0
> (gdb) p pp(null_string)
> $27 = void
> (gdb) p null_string->st
> $28 = {t = 13 '\r', flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x851b580, 
>  st_hasfillp = 0, st_adjustable = 0, st_self = 0x8b20f18 "9", st_fillp = 0, st_dim = 0}
> (gdb) 
>
> Almost sure you'd get 0x0/#<OBJNULL> for null_string.

You're right:

===================================================
>(in-package 'WRONG)

Breakpoint 1, Icall_continue_error_handler (error_name=0x1010c5e8,
   error_format_string=0x10413fa8, nfmt_args=2) at error.c:145
145       b[0]= error_name;
(gdb) p (((long)(0) + (4 -1)) & ~(4 -1))
$1 = 0
(gdb) p null_string
$2 = 0x0
(gdb) p pp(null_string)
#<OBJNULL>$3 = void
===================================================

> My suggestion:
>
> cd unixport && make raw_ansi_gcl
> then gdb raw_ansi_gcl, 'b gcl_init_error', 'r ./ <foo', and try to
> figure out what's going wrong with null_string.
On startup, saved_ansi_gcl.exe has the bad value exhibited above. 

I followed the raw_ansi_gcl suggestion today and found that 
gcl_init_error set the value of null_string correctly.  Here is a 
shortened run - I'm close to being thrown off the phone by one of the 
kids. 

===================================================
(gdb) b gcl_init_error
Breakpoint 1 at 0x41c6f3: file error.c, line 819.
(gdb) r ./ <foo
Starting program: c:\cvs\head\gcl\unixport/raw_ansi_gcl.exe ./ <foo
GCL (GNU Common Lisp)  April 1994  131072 pages

Breakpoint 1, gcl_init_error () at error.c:819
819             make_function("ERROR", Lerror);
(gdb)
(gdb) p null_string
$1 = 0x0
(gdb) n
820             make_function("CERROR", Lcerror);
(gdb) n
821             make_si_function("IHS-TOP", siLihs_top);
(gdb) n
822             null_string = make_simple_string("");
(gdb) n
823             enter_mark_origin(&null_string);
(gdb) p null_string
$2 = 0x10100d38
(gdb) p pp(null_string)
$3 = void
(gdb) p null_string->st
$4 = {t = 13 '\r', flag = 0 '\0', s = 0 '\0', m = 0 '\0',
 st_displaced = 0x64fa70, st_hasfillp = 0, st_adjustable = 0,
 st_self = 0x13e700b0 "", st_fillp = 0, st_dim = 0}
(gdb)
$5 = {t = 13 '\r', flag = 0 '\0', s = 0 '\0', m = 0 '\0',
 st_displaced = 0x64fa70, st_hasfillp = 0, st_adjustable = 0,
 st_self = 0x13e700b0 "", st_fillp = 0, st_dim = 0}
(gdb) b unexec
Breakpoint 2 at 0x4784c1: file unexnt.c, line 260.
(gdb) p &null_string
$6 = (object *) 0x64c150
(gdb) watch 0x64c150
Watchpoint 3: 6603088
(gdb) c
Continuing.
Building symbol table for c:/cvs/head/gcl/unixport/raw_ansi_gcl.exe ..
rsym_nt: c:/cvs/head/gcl/unixport/raw_ansi_gcl.exe rsym1080

===================================================

Just here it hangs (at least for five minutes.  Am I being unrealistic 
to expect unexec to work under a debugger?

I was watching the location of null_string in case it's being 
overwritten rather than something being wrong with the unexec algorithm 
per se

I'll try and poke around in the unexec process with printf debugging but 
for now I'm probably off-line for this evening.

Also, in answer to another question you asked a while ago and I 
neglected to answer - yes - I still have your modified source tree from 
the work you did on my computer.  When I looked at it at the time I 
found that your configuration was treating the build as Cygwin which is 
not good.  I think it's a bit late to be changing the entire unexec file 
for 2.6.2 though.

Also again, is it possible to get the debugger to watch for reads of a 
memory location eg to see if unexec actually reads the location of 
null_string during startup.

Cheers

Mike Thomas


> Take care,
>
>