>>>>> "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. this should be designed in from the beginning, so the debugger
>> API can be designed to work locally and over a pipe. the pipe can
>> support an rpc or message interface which is wrapped by the shared
>> debugger API.
DS> Good point. What, if anything, is needed? Is forcing the debugger
DS> to talk through STDDEBUG enough? Should we always listen (or
DS> listen when the appropriate flag's set on the command line) on
DS> some port/pipe/doodad and set a flag to kick into the remote
DS> 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. we need to get access to
the op code loop and related things. a permanent pipe thingy may be the
best solution but that should be enabled by a command line option. this
is a big security hole too if you run with remote debugging enabled. but
it is something that is needed to debug daemons and related programs
which want to use (or have none of) their own stdio.
and it implies that the debugger inside perl has a very open API which
can be wrapped for remote commands. and then there is the remote command
protocol on the pipe thingy and also the remote front end (possibly just
perl -d with the remote pipe as an arg) which needs to xlate user debug
commands to the remote pipe formats. this just doubles or triples the
amount of work needed for the debugger. we must design support in the
API for this type of stuff. it could be implemented later but the hooks
have to be in there.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
