Front page | perl.perl6.internals |
Postings from August 2001
On Sun, 26 Aug 2001, Ken Fox wrote: > Uri Guttman <uri@sysarch.com> wrote: > > >>>>> "DS" == Dan Sugalski <dan@sidhe.org> 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...) DanThread Previous