[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] Window ansi crash debug output

From: Mike Thomas
Subject: RE: [Gcl-devel] Window ansi crash debug output
Date: Wed, 28 Jan 2004 18:00:57 +1000

Hi Camm.

| The debug output is in a file called "make1.log.gz" in the usual FTP
| location.
| If you can find the time, could you please take a look at the output and
| let me know if there is anything else I should be printing to help
| narrow down the problem?   Included in the output file are symbol table
| entries for each of the object files as they are loaded and data passed
| to call_or_link() and call_or_link_closure() among others.

As it turned out I ended up mainly debugging the debugging code and adding
more symbolic information to make the addresses more meaningful.  I've
updated the log referred to above accordingly, so you need to refetch it to
see the latest information.  CVS is up-to-date with the changes I made

Here is a walkthrough of what I think I am trying to achieve.

1. We know that the call to GET-DFUN-CONSTRUCTOR during the loading of
pcl_braid.o goes wrong because part of it's code has been altered.

2. We know that the alteration is caused by the earlier call to
call_or_link_closure() for the lisp function CLASS-WRAPPER at memory
location 0x1046d140 (in the log at line 289547):

call_or_link_closure: START sym 102870b4, link 1047e494, *link 1047d43c, ptr
1046d140, *ptr 8d005ba8, sym->s.s_gfdef (fun) 104da524 Function name:
vpush_extend: item 1047e494, ar 1017f510
vpush_extend: item 1047d43c, ar 1017f510
call_or_link_closure: About to change 8d005ba8 to 104d8974 at ptr 1046d140,
1047d43c to 1047bb34 at 1047e494, then MMccall fun (after t_cclosure
vpush_extend): CLASS-WRAPPER

3. So the question is: How did that address end up as the value for ptr?

4.  Searching back through the log for 0x1046d140 gives some RDIR32
relocations associated with the symbol .bss (for example at line 221899):

    item 5777: symbol_table[567] (  22d5dc) (                  .bss):
n_value 1046d000, n_scnum 3, n_type 0, n_sclass 3, n_numaux 1 relocate:
where:        40 at  1047d440 -> new val R_DIR32    1046d140

5. I don't understand why .bss is being relocated, so I'm guessing that in
fact it's a memory location in the .bss section rather than .bss?   At the
moment that relationship eludes me.

6. Setting a conditionalised breakpoint for line 30 so that *(int *)where)
== 0x1046d140 triggers the break fails as naturally enough, the address is
different when running under the debugger.

7. Setting the condition value to be the debugger run value of 0x10316140
gives us:

    item 2422: symbol_table[567] (  22d6dc) (                  .bss):
n_value 10
316000, n_scnum 3, n_type 0, n_sclass 3, n_numaux 1
relocate: where:        40 at  1031c92d -> new val R_DIR32    10316140

Breakpoint 2, relocate () at rel_coff.c:31
31              break;

(gdb) p *0x10316140
$1 = -1929356648
(gdb) p symbol_table[567]
No symbol "symbol_table" in current context.
(gdb) p 0x22d6dc
$2 = 2283228
(gdb) p (struct syment*) 0x22d6dc
$3 = (struct syment *) 0x22d6dc
(gdb) p *(struct syment*) 0x22d6dc
$4 = {n = {n_name = ".bss\000\000\000", n = {n_zeroes = 1936941614,
      n_offset = 0}}, n_value = 271671296, n_scnum = 3, n_type = 0,
  n_sclass = 3 '\003', n_numaux = 1 '\001'}
(gdb) p the_start
No symbol "the_start" in current context.
(gdb) p relocation_info.r_vaddr
There is no member named r_vaddr.
(gdb) p relocation_info
$5 = {r = {r_vaddr = 26925, r_count = 26925}, r_symndx = 567, r_type = 6}

Off to the train home now.

Mike Thomas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]