First -- wow, thanks! I tried out the stabs stuff for the JIT
yesterday, and it's really helpful to be able to step through PASM
code from within emacs's gud mode.
I had one problem, though -- whenever stepping over a keyed op (eg
"set I0, P0[3]"), gdb fails to recognize that it reaches any more
lines and instead runs the whole thing to completion and exits. If I
did 'si' twice to step two machine instructions whenever I was about
to execute a keyed op, then I could go back to stepping normally and
it would find things correctly.
That .stabs data is correct -- the keyed op and the following ops (and
all others) had the correct offsets associated with them. I still
don't have a home network connection anymore, so I couldn't download
the gdb source to figure out what was going on. But I remember
noticing that gdb prints out the current PASM line number after that
second 'si' on the keyed op.
Anyone else having this problem? (Anyone have a better workaround?)
In my local copy (currently locked away on my home hard drive, so I
can't post it from here at work), I also added stabs entries for all
the PMC registers (in addition to the current S, I, and N registers.)
You can see the PMC's data fields and type. It looks something like:
(gdb) p P0
(PMC*) 0xdeadbeef
(gdb) p *P0
{ vtable = 0xdeadbeef, pobj = { u = { int_val = 17, pmc_val = 0x17 }, flags =
381741 } }
(gdb) p *P0->vtable
{ base_type = PerlArray }
(I added an enumeration for the PMC types). I probably have the exact
data structures all wrong, but it looks something like that. Oh, and I
suspect I may be able to use an external type reference to avoid
defining all of these things. I haven't tried that yet.
And I'd just like to say that stabs is a mess. Is DWARF2 any better?
(My poor disconnected computer doesn't have any documentation on it,
so I couldn't try it out.)
