Front page | perl.perl6.internals |
Postings from August 2001
>>>>> "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. 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 --------- uri@sysarch.com ---------- http://www.sysarch.com SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com Search or Offer Perl Jobs -------------------------- http://jobs.perl.orgThread Previous | Thread Next