hi,

i've now trying to run your example but there is one problem: i cannot set $DB::trace to 4! when i execute "$DB::trace |= 4;" as comand in the debugger, it doesn't change the trace value(because the eval block saves the $DB::trace content before evaluating "$DB::trace |= 4;" and reset the content saved in $DB::trace after evaluating)!
how can i set the $DB::trace to 4?

thx mseele

Joe McMahon wrote:

On Tue, 22 Nov 2005, Michael Seele wrote:

hi,

i write on a (java) gui for the perl debugger and have a problem: when i use the perl debugger i can suspend the execution with CTRL+C. i talk over a socket with the perl debugger process and the problem is that i can't send CTRL+C from the java programm to the perl process. for this reason i should extend the perl debugger: i will send a special command(e.g. SUSPEND) to the perl debugger and the debugger should execute the method bundeled with $SIG{INT}(catch() method).
is this possible?
i think i can override the DB method of the debugger and check for the special command. after checking i would like to call the original DB method. here are my little try:

PERL5DB={ package DB; our @ISA='DB'; sub DB { } }

but when i doe this i got errors everytime. can you help my how to override the debugger!?


Are you trying to catch the program in mid-execution and halt it? That might take a bit of diddling about to do, since the debugger's not reading from its input filehandle during continuous execution. A watchfunction() could possibly check for input pending on the debugger's input filehandle using 3-argument select() and interrupt execution based on that (it can set $DB::single, which drops the debugger back into single-step mode).

Normally this would be a bad idea (if the user started typing anything, the program would suddenly stop running), but since the GUI's controlling access to the debugger, it should work fine. Here's a basic cut at doing this; you will probably have to tweak it a bit to make sure that it works properly.

Just before going into continuous execution, execute "$DB::trace |= 4;" (sending this to the debugger directly is as good as any way to do it). This tells the debugger to enable the watchfunction.

In your .perldb (or perldb.ini, on Windows), add this:

sub watchfunction {
  my $rin = ''; my $rout;
  vec($rin,fileno(DB::IN),1)=1;

  # Wait 5 milliseconds for input to be present.
  $DB::single |= 1
    if select($rout=$rin, undef, undef, 0.05);
}

This will define the watchfunction for you (note that this way you need no mods to the debugger). Here's how it goes:

Normally, you're executing without the watchfunction (the program's not running continuously). When your interface wants to start continuous execution (the 'c' command, most likely; possibly if you want to be able to interrupt the execution of code entered by the user), set $DB::trace to turn on the watchfunction, and then issue the 'c' command. Before each statement, the watchfunction looks to see if anything is queued up on DB::IN, and sets $DB::single (which stops continuous execution), dropping you back into single-step mode, and giving you control again.

You don't have to create the watchfunction in .perldb; you can actually send it to the debugger as one long line and define it that way.

I note that the select() documentation notes that this may not work for buffered filehandles, but as I recall, we unbuffer DB::IN, so this will probably work fine. I can't guarantee it, but this is probably your best angle of attack to get things in place with the minimum fuss.

 --- Joe M.



--
G & H Softwareentwicklung GmbH     Tel.: +49(0)7451/53706-20
Robert-Bosch-Str. 23               Fax:  +49(0)7451/53706-90
D-72160 Horb a.N. http://www.guh-software.de

Reply via email to