From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kevin Buettner <kevinb@cygnus.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>, "Glenn F. Maynard" <g_gdb@zewt.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb: detection and/or fork+gethostbyname crash workaround?
Date: Tue, 24 Jul 2001 13:44:00 -0000
Message-id: <1010724204353.ZM20741@ocotillo.lan>
References: <20010723210115.B1359@zewt.org> <1010724155219.ZM20181@ocotillo.lan> <20010724142248.A2923@zewt.org> <20010724132604.A18052@nevyn.them.org> <dmj+@andrew.cmu.edu>
X-SW-Source: 2001-07/msg00347.html

On Jul 24,  1:26pm, Daniel Jacobowitz wrote:

> > That's what I tried (x86 Linux); a process can't ptrace itself.  I could
> > fork a process to test this, I suppose; I'll try that.  (Wouldn't it
> > be the return status from ptrace(), though?  I assume it'd return something
> > like EPERM if a process is already being debugged.)
> 
> Try ptrace( PTRACE_TRACEME, ...) ?

Actually, what I had in mind was for a child process to call
ptrace (PTRACE_ATTACH, ...) with the pid of the parent.  (And then, if
that succeeds immediately call ptrace (PTRACE_DETACH,...).

The reason for for not using PTRACE_PTRACEME is that it is unlikely
that the parent will know what to do with various wait messages
that'll be sent to it.  (I.e, you don't want to call PTRACE_TRACEME
unless your parent is actually a debugger.)

However, there are other approaches that Glenn may wish to try.  See

    http://sources.redhat.com/ml/gdb/2001-07/msg00346.html

We should also try to fix GDB so that all breakpoints are removed
when the inferior decides to do a fork().  (The trick will be to
restore them, but the footnote in the above link outlines how it
might be done.)

Kevin