Re: gcv_object_t in the debugger

[Bruno H. <br...@cl...>]

> > 3) As for now I can't understand the memory layout of gcv_object_t
> > which seems to contain type information along with address of some
> > other objects in the memory. It would be quite beneficial if you could
> > point out some information to get it clear.
> I hope Bruno will clarify this.

Depending on the memory model (HEAPCODES or TYPECODES), the information
in the gcv_object_t contains less or more type-related information. Plus
the address, of course. Peruse the macros in lispbibl.d to learn about how
to write code that uses it.

When you are in the debugger, it's a different story: You have lots of
hexadecimal numbers and want to make sense of them. It's not immediate
to deduce from lispbibl.d, because of the multitude of #ifs and of
macros in there. So, the first thing is to do
  $ make lispbibl.h
This produces a file lispbibl.h, that contains JUST the macros for the
current platform and memory model.

You can use the 'xout' macro defined in .gdbinit (well, after you told
gdb to actually consider this file:
  # See https://sourceware.org/gdb/onlinedocs/gdb/Auto_002dloading-safe-path.html
  add-auto-load-safe-path /my/developmentdir/CLISP

But there are situations where 'xout' is not applicable. So, one needs
to do it by hand. Let's take an example:

(gdb) where
#0  error (errortype=division_by_zero, errorstring=0x818b032 "~S: division by zero") at ../src/error.d:400
#1  0x0810bf6c in divide_0 () at ../src/aridecl.d:347
#2  0x0810c6a9 in FF_FF_div_FF (x1=<optimized out>, x2=<optimized out>) at ../src/ffloat.d:604
#3  0x08128c0b in C_slash (argcount=1, rest_args_pointer=0xf7904028) at ../src/lisparit.d:773
#4  0x0807c8c7 in eval_subr (fun=0x82582c6 <subr_tab_data+27750>) at ../src/eval.d:3599
#5  eval1 (form=<optimized out>, form@entry=0x680aa30a) at ../src/eval.d:3085
#6  0x0807d1b5 in eval (form=0x680aa30a) at ../src/eval.d:2967
#7  0x080fe2f1 in C_read_eval_print () at ../src/debug.d:409
#8  0x08070bf2 in funcall_subr (fun=0x8252b66 <subr_tab_data+5382>, args_on_stack=<optimized out>) at ../src/eval.d:5223
#9  0x080fe59b in driver () at ../src/debug.d:490
#10 0x0806e69d in main_actions (p=0x82688e0 <argv2>) at ../src/spvw.d:3787
#11 0x0805f234 in main (argc=1, argv=0xffffcae4) at ../src/spvw.d:4053

Let's look at the frame #6:
form=0x680aa30a

A form being evaluated with recursion is almost always a CONS. That is, it's
a heap-allocated object. The address is 0x680aa30a & 0xfffffffc, because on x86
all words are aligned modulo 4. The extra '2' in the low bits is the type
indicator for CONS. So, to look at it, do

(gdb) print *(void*(*)[2]) 0x680aa308
$1 = {0x680aa302, 0x82604ae <symbol_tab_data+29382>}

When you look at the definition of type 'Cons' in lispbibl.d, you see that
the CDR comes first, then the CAR. For a form, we want to look at the CAR
first: 0x82604ae. Again, ignore the low 2 bits:

(gdb) print *(void*(*)[8]) 0x82604ac
$6 = {0x82604ae <symbol_tab_data+29382>, 0x60120, 0x82591ee <symbol_tab_data+6>,
      0x82582c6 <subr_tab_data+27750>, 0xfffffffc, 0x82591ee <symbol_tab_data+6>,
      0x202ca576, 0x202bdace}

The first word is a self-pointer; this word is used by GC, and the fact that
we see it pointing to itself is an indication that we are really at the beginning
of a non-CONS object. Next comes a word of flags: 0x60120. Peruse the definition
of 'Symbol':
  gcv_object_t symvalue    0x82591ee <symbol_tab_data+6>
  gcv_object_t symfunction 0x82582c6
  gcv_object_t hashcode    0xfffffffc
  gcv_object_t proplist    0x82591ee <symbol_tab_data+6>
  gcv_object_t pname       0x202ca576
  gcv_object_t homepackage 0x202bdace
The first symbol_tab_data element is NIL; good to remember.
Here what we need to identify the symbol is its pname: 0x202ca576.
 Again, ignore the low 2 bits:

(gdb) print *(void*(*)[8]) 0x202ca574
$7 = {0x202ca576, 0x412, 0x2f, 0x0, 0x202ca586, 0x811, 0x2b31, 0x0}

The print name usually occupies 1 byte per character (it's all ASCII),
therefore you can use the (char*) view:

(gdb) print (char*)(0x202ca574 + 8)
$8 = 0x202ca57c "/"

So, we found that the form above begins with the symbol '/'.

Debugging can become more complex than this; but you got the idea.

Bruno