Re: gdb/1922: `gdb -p' fails on FreeBSD unless procfs is mounted

[David Schultz <das at FreeBSD dot ORG>]

The following reply was made to PR gdb/1922; it has been noted by GNATS.

From: David Schultz <das@FreeBSD.ORG>
To: Paul Gilliam <pgilliam@us.ibm.com>
Cc: gdb-prs@sources.redhat.com, gdb-gnats@sources.redhat.com,
        marcel@FreeBSD.ORG
Subject: Re: gdb/1922: `gdb -p' fails on FreeBSD unless procfs is mounted
Date: Wed, 20 Apr 2005 08:06:59 -0400

 On Tue, Apr 19, 2005, Paul Gilliam wrote:
 > On Monday 18 April 2005 22:13, das@FreeBSD.ORG wrote:
 > > 
 > > >Number:         1922
 > > >Category:       gdb
 > > >Synopsis:       `gdb -p' fails on FreeBSD unless procfs is mounted
 > > >Confidential:   no
 > > >Severity:       serious
 > > >Priority:       medium
 > > >Responsible:    unassigned
 > > >State:          open
 > > >Class:          patch
 > > >Submitter-Id:   net
 > > >Arrival-Date:   Tue Apr 19 05:18:00 UTC 2005
 > > >Closed-Date:
 > > >Last-Modified:
 > > >Originator:     das@FreeBSD.ORG
 > > >Release:        6.1.1
 > > >Organization:
 > > >Environment:
 > > FreeBSD VARK.MIT.EDU 6.0-CURRENT FreeBSD 6.0-CURRENT #7: Sun Apr 17 20:58:41 EDT 2005 das@VARK.MIT.EDU:/usr/scratch/vark/usr/home/t/freebsd/vark/src/sys/GENERIC  i386
 > > >Description:
 > > Invoking `gdb -p' on FreeBSD without procfs mounted causes gdb to crash because it can't find the process' executable file.  Subsequently, the target process is killed.  There are really two problems here:
 > > 
 > > (1) gdb should use a different mechanism to find the
 > >     text file on FreeBSD.
 > > 
 > > (2) gdb should cleanly detach from the process when it
 > >     detects an internal error such as this so the
 > >     process isn't killed.
 > 
 > This might not always be "The Right Thing".  The user should be able
 > to choose: clean detach to kill.
 
 For internal errors, that's certainly a reasonable course of action.
 However, in this case we're dealing with an external error (couldn't
 find the process' text file) that is handled improperly and reported
 as an arcane internal error.  It (hopefully) isn't as though gdb
 needs to be worried that it accidentally corrupted the internal state
 of the application.  Hence, the only question gdb needs to ask is
 whether it should try to continue debugging without symbols or
 cleanly detach.