From owner-freebsd-hackers Wed Dec 6 16:42:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 16:42:14 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 156B137B400 for ; Wed, 6 Dec 2000 16:42:13 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id eB70gAW36778; Wed, 6 Dec 2000 19:42:11 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id eB70g9d03226; Wed, 6 Dec 2000 19:42:10 -0500 (EST) (envelope-from bsd) Date: Wed, 6 Dec 2000 19:42:09 -0500 From: Brian Dean To: Zhiui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ptrace(PT_GETDBREGS) message in remote debugging Message-ID: <20001206194209.B94389@vger.bsdhome.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Wed, Dec 06, 2000 at 01:04:36PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 06, 2000 at 01:04:36PM -0500, Zhiui Zhang wrote: > I tried remote debugging on FreeBSD 4.2 this morning. Everything was > fine, except that I saw the following messages: > > (gdb) step > ptrace(PT_GETDBREGS) failed: No such process > ptrace(PT_GETDBREGS) failed: No such process > ptrace(PT_GETDBREGS) failed: No such process > 201 cred = p ? p->p_ucred : NOCRED; > > This ptrace stuff never appear before. Is this a new feature or was I > doing something wrong? > > Any help is appreciated. You're not doing anything wrong, and this is a new feature. The problem is that gdb is trying to load the debug registers for its target process, except that it doesn't realize that it's a remote target. In looking through the GDB code, its not at all obvious to me how to determine this fact, except maybe by checking inferior_pid against MAGIC_NULL_PID, but that is defined local to remote.c only. The following patch below simply checks the return code from ptrace() and doesn't complain of the pid is not found, making the assumption that if the pid is not found, it must be a remote target. Whether or not this is a valid assumption or not in all cases, I'm not sure. The patch is against -STABLE, but I don't think this has diverged any from -CURRENT. Give this a try and let me know. -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com Index: freebsd-nat.c =================================================================== RCS file: /usr00/FreeBSD/mirror/ncvs/src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c,v retrieving revision 1.21.4.2 diff -u -r1.21.4.2 freebsd-nat.c --- freebsd-nat.c 2000/08/22 12:28:19 1.21.4.2 +++ freebsd-nat.c 2000/12/07 00:31:52 @@ -478,14 +478,16 @@ { struct dbreg dbr; extern int inferior_pid; - + if (inferior_pid != 0 && core_bfd == NULL) { int pid = inferior_pid & ((1 << 17) - 1); /* XXX extract pid from tid */ - + if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); return 0; } #if WATCHPOINT_DEBUG > 1 @@ -520,7 +522,10 @@ if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); + return 0; } @@ -615,7 +620,9 @@ if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); return 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message