On Tue, Jul 1, 2008 at 3:33 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/7/1 Eliot Miranda <eliot.miranda at gmail.com>:
> > Hi Igor,
> >     this looks cool.  It is related to David Ungar's Klein which was an
> > attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk,
> > and Ian's Cola.  Whenever I've thought about this style VM I've always
> been
> > put off by a bug issue.  How are you going to deal with hard crashes?
> > One needs some form of symbolic debugging at the machine code level.  If
> one
> > is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one
> > can compile a version with debug symbols, use the platform's debugger
> (e.g.
> > gdb) and write debugging functions in C to be called from that debugger.
> > If one has a self-hosted Smalltalk system with no symbolic information
> that
> > can be read by a platform's debugger because the system, being Smalltalk,
> > has is own fully reflective self-description, then it seems to me one
> really
> > is fishing about in a vast hex dump of the entire system, and that
> doesn't
> > seem workable.  Note that in the presence of a hard crash one doesnt have
> > the system to debug itselr because it has just crashed.
>
>
> I have some thoughts about using properly set exception handling mechanism.
> In Windows its a Structured Exception Handling (SEH) , provided by OS,
> in unixes there is need to set up a signal handlers.
> So, if properly set up, it is possible to debug most of errors without
> using external debugger process, and you don't have to generate any
> symbolic info for them.
> There are vast possible options and solutions. As Ralph mentioned, it
> can keep 2 object memories - one for running image, second for
> controlling it.
>
>
> > So are you going to export symbolic information that a platform debugger
> can
> > consume (and if so, how?) or are you going to do something else (e.g.
> > mirrors)?
> >
>
> Good question, i need to think about it. I don't think it would be
> easy to bind such info with platform debugger (because they all are
> C-centric and its unlikely that they will be able to find any info in
> freely movable code ;) ), what i think is more realistic, that we can
> run an image containing debugger, and provide enough interface in
> running image, so debugger can extract all required info from process
> being debugged.


This is the "mirrors" approach I alluded to.  The right approach is to
implement the debugger with a mirror between it and the system it looks at.
 There is a mirror for local debugging taht is fairly transparent.  then
there is a mirror for the renoter system which is much more involved because
it has to use peek and poke to examine the memory space of the target
process and it has to extract meta information   from it (and in the
presence of errors, e.g. the hard crash could have corrupted memory).

Let me encourage you to think about this soon and work on it asap because it
is a really important issue.  If you don't have a good debugging environment
up front your progress will be slow.  No one has succeeded in bringing such
a system for a Smalltalk-like language into production use yet (neither
Klein nor TypedSmalltalk nor Exupery has made it to production use).  Making
it happen would be fantastic.  You have the Spoon system to build upon.

You have to both provide a Smalltalk-level debugger and a machine code
debugger which can display machine instructions, registers and memory.  It
would be nice to be able to reuse disassemblers et al from other components
but you might find that Smalltalk implementations are quicker to write and
easier to understand and use.  But you will need them.

Best
Eliot

>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/65ee6554/attachment.htm