From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12510 invoked by alias); 3 May 2010 13:51:38 -0000 Received: (qmail 12496 invoked by uid 22791); 3 May 2010 13:51:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from aussmtpmrkps320.us.dell.com (HELO aussmtpmrkps320.us.dell.com) (143.166.224.254) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 May 2010 13:51:03 +0000 X-Loopcount0: from 12.110.134.31 Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 03 May 2010 08:51:01 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PING] [RFC] Thread debug support for NetBSD 5 Date: Mon, 03 May 2010 13:51:00 -0000 Message-ID: In-Reply-To: <201004291638.50078.pedro@codesourcery.com> References: <19405.52446.728141.329821@pkoning-laptop.equallogic.com> <19408.27827.830391.509465@pkoning-laptop.equallogic.com> <19417.40044.762978.858637@pkoning-laptop.equallogic.com> <201004291638.50078.pedro@codesourcery.com> From: "Paul Koning" To: "Pedro Alves" , X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00038.txt.bz2 > > +static int pending_sigs; >=20 > I'm not sure whether this global can get stale between > debug sessions or not, but it looked like it. Say, if you > kill a process while you have pending sigs, the next > debug session will trip on it being !=3D 0?=20 Probably true, I'll fix that. > It also points > out that you should probably do something to the pending > signals when you go about detaching from a process, so > they don't get lost. No, this variable is for reporting signals to gdb, so on a detach it can/should be cleared. =20 > > + if (catch_syscall_enabled () > 0) > > + request =3D PT_SYSCALL; > > + else > > + request =3D PT_CONTINUE; >=20 > I think this will be dead code, since you don't > support inserting catch syscalls. I copied that code out of inf-ptrace.c which is the common target code for targets that use ptrace. NetBSD was using that before.=20 =20 > > + /* An address of (PTRACE_TYPE_ARG3)1 tells ptrace to continue from > > + where it was. If GDB wanted it to start some other way, we > have > > + already written a new program counter value to the child. */ > > + errno =3D 0; >=20 > If this clearing of errno is needed, then it should move to just > before the `ptrace' calls. You have several function calls between > this and the `ptrace' calls (at least when debugging is enable), > and any of those could clobber `errno'. (That's the reason > for `save_errno' in your patch somewhere else, BTW.) Right, I missed that when I added the debug messages. Thanks. =20 > > + /* If nothing found in the no wait case, report that. */ > > + if (options =3D=3D WNOHANG && pid =3D=3D 0) > > + return pid_to_ptid (-1); >=20 > Use minus_one_ptid, here and everywhere else. >=20 >=20 > > +static char * > > +nbsd_thread_pid_to_str (struct target_ops *ops, ptid_t ptid) > > +{ > > + if (TIDGET (ptid) =3D=3D 0) > > + { > > + struct target_ops *beneath =3D find_target_beneath (ops); > > + > > + return beneath->to_pid_to_str (beneath, ptid); > > + } > > + return xstrprintf (_("Thread %ld"), TIDGET (ptid)); >=20 > This leaks. Nothing ever releases the return of > target_pid_to_str calls; that's why all implementations > return a pointer to a static buffer. Oops. I copied that from dec-thread.c. =20 paul