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

[Camm Maguire]

Hi Mike!  OK, I think we have something.

We were a bit hasty in concluding that the loaded object's memory
image as reported just after fasload matched the image at the point of
execution in call_or_link.

You write in 

http://mail.gnu.org/archive/html/gcl-devel/2004-01/msg00052.html

that at

cmpaux.c:315

the value of 

p/x *(char *)0x1030c130

is 

(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, ...}


Which lines up nicely with your dump from pcl_dfun.o.dump:

00000130 <_L2>:
     130:       55                      push   %ebp
     131:       57                      push   %edi
     132:       56                      push   %esi
     133:       53                      push   %ebx
     134:       83 ec 1c                sub    $0x1c,%esp
     137:       8b 35 00 00 00 00       mov    0x0,%esi
     13d:       8b 0d 00 00 00 00       mov    0x0,%ecx
     143:       8d 46 18                lea    0x18(%esi),%eax
     146:       3b 0d 00 00 00 00       cmp    0x0,%ecx

modulo relocations, which has updated the 3 sequences of 4 null bytes
each. 

However, at

funlink.c:71

you report

p/x *(char *)fun->cf.cf_self

as 

(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, ...}
(gdb)

Something has trampled on the code starting at 0x1030c140 for 4 bytes,
probably an integer assignment.  

If you could (after reaching the call_init breakpoint) do

watch *0x1030c140

I think we'll nab the culprit.

Take care,


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