On Sun, 26 Aug 2001, Ken Fox wrote:
> Uri Guttman <[EMAIL PROTECTED]> wrote:
> > >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> > DS> At 03:22 PM 8/18/2001 -0400, Uri Guttman wrote:
> > >> i didn't see any references to support debugging an external perl
> > >> process. ...
> >
> > DS> Good point. ... listen on some port/pipe/doodad and set a flag
> > DS> to kick into the remote debugger if someone connects to it?
> >
> > this is a tricky problem as we can't just grab the remote process like
> > gdb can these days using /proc or something.
>
> Why can't we do that?
>
> The way I'd really like to kick in the debugger is to start up gdb
> and just say:
>
> (gdb) call perl_debug_enable()
> (gdb) continue
Hmmm. Yeah, that would be nifty, wouldn't it? Shouldn't be that tricky
either, if we do things properly.
> It would be very useful to have a collection of gdb-callable
> routines for integrating the Perl debugger with perl (internals)
> debugging.
That's one of the points in getting the debugging PDD done now, so we can
make allowances for this sort of thing.
> The other thing that I would like is a way of pausing in Perl code
> and waiting for a debugger to attach. This would make it much easier
> to debug mod_perl for example.
Sure, that makes sense. debug_wait() or something.
> It seems like overkill (and a security nightmare) to come up with a
> special remote debugging solution. Is there some reason we're going
> to need to debug perl on a platform without a real debugger? You
> don't have any plans to compete with Java in the embedded device
> space, do you Dan? ;)
Compete? Nah. Overwhelm, maybe. :) (Or just assimilate if teh jave
bytecode ->perl bytecode translator works out...)
Dan
