From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15656 invoked by alias); 11 Oct 2008 02:50:04 -0000 Received: (qmail 14635 invoked by uid 22791); 10 Oct 2008 23:48:15 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Oct 2008 23:47:40 +0000 Received: (qmail 13171 invoked from network); 10 Oct 2008 23:47:38 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Oct 2008 23:47:38 -0000 From: Pedro Alves To: Thomas Schwinge Subject: Re: GDB HEAD (partly) broken for GNU/Hurd Date: Sat, 11 Oct 2008 02:50:00 -0000 User-Agent: KMail/1.9.9 Cc: uweigand@de.ibm.com, gdb@sourceware.org, "Alfred M. Szmidt" , bug-hurd@gnu.org References: <20081009093424.GN7127@fencepost.gnu.org> <200810091255.17394.pedro@codesourcery.com> <20081010232706.GG21737@fencepost.gnu.org> In-Reply-To: <20081010232706.GG21737@fencepost.gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810110047.39807.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00043.txt.bz2 On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote: > On HEAD, when undoing this change (and additionally commenting out the > two ``stop_soon = X'' lines in that file), things are fine again. > > As most of GDB's internals are a big black box to me, I need help here. > :-) > Eh, I did point out at the time of that change that gnu-nat.c does things a bit different. :-) Off-hand advice: One thing that the hurd has a bit different, is that we have multi-threading when going through the shell. Could it be that target_wait is returning a specific ptid here: fork_child.c:startup_inferior: while (1) { int resume_signal = TARGET_SIGNAL_0; ptid_t resume_ptid; struct target_waitstatus ws; memset (&ws, 0, sizeof (ws)); resume_ptid = target_wait (pid_to_ptid (-1), &ws); ^^^^^^^^^^^ Hence this a bit below: if (--pending_execs == 0) break; /* Just make it go on. */ target_resume (resume_ptid, 0, TARGET_SIGNAL_0); ^^^^^^^^^^^ } } Doesn't resume the whole shell? If you make this change: - target_resume (resume_ptid, 0, TARGET_SIGNAL_0); + target_resume (minus_one_ptid, 0, TARGET_SIGNAL_0); The other thing I suggest to look at, is to make sure the local `pending_execs' and the `gnu-nat.c:struct inf'::pending_execs aren't in conflict, but it doesn't look like it. Hope this helps. -- Pedro Alves