Re: [Gcl-devel] HEAD Maxima and HEAD trad GCL

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> | > The function name
> | GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE seems to
> | > be a bogus overwriting of several names in pcl_dfun - something is going
> | > badly wrong with string handling?
> |
> | GCL strings are not null terminated.  The length is rather given by
> | the fillp argument.  This is OK.
> 
> Good: I was a bit suspicious about the way those pathnames are being doubled
> up in the Maxima defsystem.lisp.
> 
> | > Keep in mind when reflecting on this that on Windows, uninitialised
> | > variables do not get automatically set to 0, they are set to whatever is
> | > sitting in memory when they are instantiated.
> | >
> |
> | Nor in Linux.
> 
> I have been worried for two years that we might be working at crossed
> purposes over issues like this one.  Is it an Intel architecture thing or
> simply an OS design decision?
> 

AFAICT, malloc never initializes its memory by definition in the C
standard.   mmap, which may be Linux specific, fills in with zeroes
when maps are extended.  One could implement malloc on top of this if
one wanted.  But no C program can count on malloc initializing memory,
and in some performance-sensitive cases, one wants to make sure that
this in fact is not done unnecessarily.


> OK redoing that dump at the call_or_link call with (char *):
> 
> (gdb) b funlink.c:71
> Breakpoint 4 at 0x4314a4: file funlink.c, line 71.
> (gdb) cond 1 fun->cf.cf_self == 0x1030c130
> No breakpoint number 1.
> (gdb) cond 4 fun->cf.cf_self == 0x1030c130
> (gdb) r
> Starting program: c:\cvs\head\gcl\pcl/../unixport/saved_gcl.exe
>         0x005407A0 BSS start in memory.
>         0x004e0000 BSS offset in saved executable.
>         0x00113710 BSS size in bytes.
>         0x00113710 bytes read.
>         0x10100000 Heap start in memory.
>         0x00400000 Heap offset in executable.
>         0x000e0000 Heap size in bytes.
>         0x10100000 file base.
> GCL (GNU Common Lisp)  (2.7.0) Mon Jan  5 18:01:01 EAST 2004
> Licensed under GNU Library General Public License
> 
> ...
> blah blah
> ...
> 
> Breakpoint 4, call_or_link (sym=0x1022c3a8, link=0x1031d57c) at funlink.c:71
> 71                  ( *(void (*)()) (fun->cf.cf_self)) ();
> (gdb) p fun->cf.cf_name->st
> $18 = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced =
> 0x0,
>   st_hasfillp = 4784, st_adjustable = 84,
>   st_self = 0x103ce800 "GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE",
>   st_fillp = 20, st_dim = 270352720}
> 
> 
> 
> (gdb) p/x *(char *)fun->address@hidden
> $20 = {0x55, 0x57, 0x56, 0x53, 0x83, 0xec, 0x1c, 0x8b, 0x35, 0xa0, 0xb,
> 0x5b,
>   0x0, 0x8b, 0xd, 0x10, 0xf4, 0x8b, 0x29, 0x10, 0x46, 0x18, 0x3b, 0xd, 0xd0,
>   0x7d, 0x5a, 0x0, 0x89, 0x74, 0x24, 0x18, 0x89, 0x44, 0x24, 0x14, 0xf,
> 0x83,
>   0x6b, 0x4, 0x0, 0x0, 0x89, 0xc8, 0x29, 0xf0, 0xc1, 0xf8, 0x2, 0x85, 0xc0,
>   0xf, 0x8e, 0x46, 0x4, 0x0, 0x0, 0x83, 0xc6, 0x4, 0x8b, 0x54, 0x24, 0x18,
>   0x39, 0xf1, 0x8b, 0x2a, 0x89, 0x35, 0xa0, 0xb, 0x5b, 0x0, 0xc7, 0x1, 0xb0,
>   0x12, 0x54, 0x0, 0x89, 0xcb, 0xf, 0x87, 0x4, 0x4, 0x0, 0x0, 0x8b, 0x44,
>   0x24, 0x14, 0xa3, 0x10, 0x78, 0x5a, 0x0, 0xa1, 0xa8, 0xcd, 0x31, 0x10,
> 0x8b,
>   0x4c, 0x24, 0x18, 0x81, 0x78, 0x4, 0xb0, 0x12, 0x54, 0x0, 0x8b, 0x79, 0x4,
>   0x74, 0x30, 0x8b, 0x1d, 0xac, 0xcd, 0x31, 0x10, 0x81, 0xfb, 0xb0, 0x12,
>   0x54, 0x0, 0x74, 0x22, 0x83, 0xec, 0x8, 0xff, 0x73, 0x8, 0x55, 0xe8, 0x60,
>   0xc3, 0x14, 0xf0, 0x83, 0xc4, 0x10, 0x85, 0xc0, 0xf, 0x85, 0x3e, 0x3, 0x0,
>   0x0, 0x8b, 0x5b, 0x4, 0x81, 0xfb, 0xb0, 0x12, 0x54, 0x0, 0x75, 0xde, 0xa1,
>   0xa0, 0xcd, 0x31, 0x10, 0x8b, 0x40, 0x4, 0x3d, 0xb0, 0x12, 0x54, 0x0,
> 0x74,
>   0x19, 0x8d, 0x76, 0x0, 0x8b, 0x50, 0x8, 0x3b, 0x6a, 0x8, 0xf, 0x84, 0x0,
>   0x3, 0x0, 0x0, 0x8b, 0x40, 0x4, 0x3d...}
> (gdb)
> 

Thanks for this.  This does indeed match with the objdump you sent
separately.  The Little Endian integers on x86 reversed the byte order
in groups of four in the previous output, confusing me.

> 
> 
> Loading binary of PCL_DFUN...
> 
> Breakpoint 5, fasload (faslfile=0x1024cfc0) at sfasl.c:178
> 178         int init_address=0;
> (gdb) p faslfile->s
> $21 = {t = 13 '\r', flag = 0 '\0', s = 0 '\0', m = 0 '\0', s_dbind =
> 0x5412b0,
>   s_sfdef = 0,
>   st_self = 0x103b5a2c "c:/cvs/head/gcl/unixport/../pcl/pcl_dfun.o",
>   st_fillp = 42, s_gfdef = 0x2a, s_plist = 0xd, s_hpack = 0x5412b0,
>   s_stype = 0, s_mflag = 0}
> (gdb) break call_init
> Breakpoint 6 at 0x418fa3: file cmpaux.c, line 315.
> (gdb) c
> Continuing.
> 
> Breakpoint 6, call_init (init_address=0, memory=0x102d6294,
>     fasl_vec=0x10112ab8, fptr=0) at cmpaux.c:315
> 315       check_type(fasl_vec,t_vector);
> (gdb) p init_address
> $22 = 0
> (gdb) p memory->cfd
> $23 = {t = 27 '\e', flag = 0 '\0', s = 0 '\0', m = 0 '\0',
>   cfd_start = 0x1030c000 "\2038\030h\220-1\020F--\020=\203-\034+\215v",
>   cfd_size = 71920, cfd_fillp = 0, cfd_self = 0x0}
> 
> 
> And, If I understand you correctly, now dumping at memory->cfd.cfd_start +
> 0x130 which is the offset for L2:
> 
> 
> (gdb) p memory->cfd.cfd_start + 0x130
> $25 = 0x1030c130 "UWVS\2038\034\2135a\v["
> (gdb) p/x *(char *)address@hidden
> $26 = {0x55, 0x57, 0x56, 0x53, 0x83, 0xec, 0x1c, 0x8b, 0x35, 0xa0, 0xb,
> 0x5b,
>   0x0, 0x8b, 0xd, 0x10, 0x78, 0x5a, 0x0, 0x8d, 0x46, 0x18, 0x3b, 0xd, 0xd0,
>   0x7d, 0x5a, 0x0, 0x89, 0x74, 0x24, 0x18, 0x89, 0x44, 0x24, 0x14, 0xf,
> 0x83,
>   0x6b, 0x4, 0x0, 0x0, 0x89, 0xc8, 0x29, 0xf0, 0xc1, 0xf8, 0x2, 0x85, 0xc0,
>   0xf, 0x8e, 0x46, 0x4, 0x0, 0x0, 0x83, 0xc6, 0x4, 0x8b, 0x54, 0x24, 0x18,
>   0x39, 0xf1, 0x8b, 0x2a, 0x89, 0x35, 0xa0, 0xb, 0x5b, 0x0, 0xc7, 0x1, 0xb0,
>   0x12, 0x54, 0x0, 0x89, 0xcb, 0xf, 0x87, 0x4, 0x4, 0x0, 0x0, 0x8b, 0x44,
>   0x24, 0x14, 0xa3, 0x10, 0x78, 0x5a, 0x0, 0xa1, 0xa8, 0xcd, 0x31, 0x10,
> 0x8b,
>   0x4c, 0x24, 0x18, 0x81, 0x78, 0x4, 0xb0, 0x12, 0x54, 0x0, 0x8b, 0x79, 0x4,
>   0x74, 0x30, 0x8b, 0x1d, 0xac, 0xcd, 0x31, 0x10, 0x81, 0xfb, 0xb0, 0x12,
>   0x54, 0x0, 0x74, 0x22, 0x83, 0xec, 0x8, 0xff, 0x73, 0x8, 0x55, 0xe8, 0x60,
>   0xc3, 0x14, 0xf0, 0x83, 0xc4, 0x10, 0x85, 0xc0, 0xf, 0x85, 0x3e, 0x3, 0x0,
>   0x0, 0x8b, 0x5b, 0x4, 0x81, 0xfb, 0xb0, 0x12, 0x54, 0x0, 0x75, 0xde, 0xa1,
>   0xa0, 0xcd, 0x31, 0x10, 0x8b, 0x40, 0x4, 0x3d, 0xb0, 0x12, 0x54, 0x0,
> 0x74,
>   0x19, 0x8d, 0x76, 0x0, 0x8b, 0x50, 0x8, 0x3b, 0x6a, 0x8, 0xf, 0x84, 0x0,
>   0x3, 0x0, 0x0, 0x8b, 0x40, 0x4, 0x3d...}
> (gdb)
> 
> 
> Which seems to match up OK?
> 

OK!  Now the procedure is to set breakpoints at the addresses
corresponding to the 'calls' reported in your pcL_dfun dump file.  
I.e. the first one is reported at offset 1bb, which at your load
address is 0x1030c1bb, so you can break right before and right after,
with b *0x1030c1bb and b *0x1030c1c0.  You want to find the call which
does not return to the following instruction.  

You can also look at the C source, and break at the functions called
by their name as a cross check.  I.e. if arguments are passed, the
first would be b make_cons, and then b eql.

My guess now is that one of the function addresses used in this
function in calling another has not been properly relocated.  Once we
identify the function call that does not return, we can then inspect
and report the register and stack content right before the call.

Apart from this main line of inquiry, I'd also like you to try a build
with --enable-dlopen, if mingw has such.  If the above gets tedious, I
can show you how to build an image with the pcl objects linked via ld,
so that debugging in gdb will refer you directly to the compiled C
source.  

Take care,

> Cheers
> 
> Mike Thomas.
> 

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