This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile-vm-0.0


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > > Debugging support is the concern I have about my VM.  Since bytecodes
> > > loose information about source code, I'm not sure if I can provide a
> > > good debugging interface. (Nobody want to trace assemble code)
> > 
> > It is probably possible to supplement the byte code of each closure
> > with a separate package of debugging information (much the same way
> > that object files contains extra debugging information)?  This could
> > be used to achieve source-level debugging.
> 
> Probably.  Each closure may have its own properties, so adding some
> information there is certainly possible.  Closure-level backtrace is
> not so hard.  One tricky part is, for example,
> 
>   (define (multiply a b)
>     (let loop ((result 0) (multiplier b))
>       (if (<= multiplier 0)
>           result
>           (loop (+ result a) (1- multiplier)))))
> 
> This function doesn't call any closure, so if one want to execute it
> in step, the debugger must emulate execution instead of having the VM
> execute one step.  VM's one step is different from that of Scheme.
>
> And emulating execution is exactly what an interpreter does.  If I want
> to add a source level debugging feature, I have to write another Scheme
> interpreter on the top of the VM, don't I?  Hmm, no, maybe I can add
> such information that tells the VM that which expression corresponds to
> which sequence of bytecodes, and then let the VM continue execution
> until the end of a Scheme expression one want to step...
> 
> So it is like what GDB does, right?

The procedure above *is* a closure.  I'll wait with looking carefully
at your VM until I've done some things I've promised to do, but I
assume there will be one chunk of byte code per closure.

What I'm suggesting is that apart from this chunk, we store a chunk of
debugging information.  Such information could contain a table which
for every Scheme level expression in the closure contains a reference
to the Scheme expression itself (or its position in a source file)
plus an index into the chunk of byte codes.

While single-stepping through the function, it is possible to have the
debugging version of the VM detect when you have reached the byte code
on next index, and make an exception.

My guess is that this is, in principle, what GDB does.  (Except that
it probably either sets a hardware breakpoint or replaces the
instruction at the index with a trap usually, and emulates the CPU
only when having set watchpoints.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]