Re: process attaching gdb to itself

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Sep 28, 2003 at 06:35:24PM -0400, Andrew Cagney wrote:
> >Hello,
> >
> >  char cmd [256];
> >  sprintf (cmd, "gdb attach %d", getpid ());
> >  system (cmd);
> >
> >'system' waits for the program that it calls to finish.
> >Thus, your program is waiting for gdb to finish before it
> >does anything.
> >
> >Try the appended program which uses raw fork/exec.
> >It works for me on red hat linux 8, native i686-pc-linux-gnu.
> >
> >If you try to do this in production code then you are likely
> >to run into a blizzard of race conditions, error cases,
> >and signal handling problems.  If you are doing this as a learning
> >experience, that's great -- read up on 'man fork' and
> >'man execlp', and check out a book on Linux systems programming.
> 
> Is the kernel Linux?  JeffJ and I just discovered that:
> 
> $ sleep 1000
> ^Z
> PID 1234 suspended
> $ gdb sleep 1234
> ...
> (gdb)
> 
> works on BSD but fails on GNU/Linux.  When doing an attach, BSD always 
> generates something for wait4 to consume. GNU/Linux does not, leaving 
> GDB stuck in wait4 :-(

Yes, I've known about this problem for a long time.  We've [I, Roland,
a couple of other people I can't recall] talked about changing it and
decided that, really, the current behavior makes more sense.

It's not at all hard to make GDB work in the current system anyway. 
Just have to do it.  It goes something like:
  - attach
  - wait4 WNOHANG, break if succeeds (optimistic, not necessary)
  - check in /proc to make sure the process is in a stopped state
    - If it was:
      - wait4 WNOHANG
        - If we get a status, then the process was running when we attached
        - If no status is available then the process was stopped when
          we attached
    - If it wasn't:
      - The process was running when we attached and hasn't stopped yet
      - wait4 without WNOHANG


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer