NarenB | 6 Sep 23:56 2009
Picon

Breaking execution after continue command


I am a WinDbg user trying to become familiar with GDB.

After issuing a continue command (resuming program execution), while the
program is running, is there a way I can break into the program ? Something
like COntrol-Break in WinDbg ?

Can we break in the first place ? Or after saying continue, the only way we
break is when the breakpoint that was previously set, gets hit ?

Thanks !!

--

-- 
View this message in context: http://www.nabble.com/Breaking-execution-after-continue-command-tp25322496p25322496.html
Sent from the Gnu - gdb - General mailing list archive at Nabble.com.

NarenB | 7 Sep 00:02 2009
Picon

GDB RSP protocol question


I am a WinDbg user trying to become familiar with GDB and RSP protocol that
GDB uses.

Can we assume that the GDB client and server communication is always a
synchronous ? That is the GDB server sends a response to the client's
request and there is no unsolicited packets from the GDB server ?

If the GDB client issues a continue command, is the only response to that is
when the breakpoint (that was set earlier on) is hit ? 

Thanks !!
--

-- 
View this message in context: http://www.nabble.com/GDB-RSP-protocol-question-tp25322566p25322566.html
Sent from the Gnu - gdb - General mailing list archive at Nabble.com.

Manoharan Vijaya Raghavan | 17 Sep 21:32 2009
Picon

Reverse debugging questions

Hi All,
 
This mail has my questions regarding reverse debugging...
1. I need not be explained in simple / basic terms...
2. I have used gdb... as well as I have done a few modifications to gdb code for
   in house usage...
3. I would like to know (and possibly contribute) what could be the probable
   solutions for the problems which I see...

Questions :-
      1. Let us say a process which you want to reverse step has created
         a file ... natuarally you are supposed to delete the file when reverse stepping
         so that at the time before executing the previous lines the file was not
         existing ... 
                  the reason I want the "system state" not just the process context
         to be same is
  Let us say my program has the following lines...
1110                printf("Let us create that file \n");
1111                if ((fd = open("xyz",O_WRONLY | O_EXCL | O_CREAT, mode)) < 0)
1112                {
1113                     /* do some error processing */
1114                     exit(1);
1115                }
1116                fwrite(fd,.............
 
         Let us say I am in the line 1116..... now I want to  step back...
         I go to the line 1110...
         Are you going to jump to the code in previous line and restore the
         process / thread context and execute the code again when user wants
         to step forward ?
         if that is the case then while stepping forward again... I will
         get an error as the file "xyz" already exists and I will be going
         to a code flow which is different that it was before...
     
         there more scenarios along the same line such as
              1. socket operations...
              2. File read / write
              3. semaphore operations...
              4. child process creations ...
              5. Signals...
              6. thread scheduling in exact reverse order as it occured before...
              etc...
       can we do a record and play back... I mean... just capture
       the "change in process state" for each and every instruction and while
       doing the reverse debugging ... just simply play it back ? then it may
       not exactly be a reverse debugging ... may be it is something else...
       a reverse play back of some core files (ofcourse diff) ...
       (is this the technique you are already using ?).....
       if not so then why can't we use this... ? just store the difference
       in thread context and memory alone each time and then play it for
       already executed instructions when user wants to step through them...
      
       In case of record and play back may be it becomes something like software
       breakpoint (an internal one) in each and every line of the process...
       In this approach (record and play) there is a limitation that  user
       cannot just like that alter the flow from an already executed
       instructions without side effects (how to cancel the effect of
       instructions already executed... i.e., restoring the system state)
 
-- The New Symbol
 

Gmane