From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21883 invoked by alias); 2 Oct 2008 08:41:40 -0000 Received: (qmail 21871 invoked by uid 22791); 2 Oct 2008 08:41:36 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Oct 2008 08:40:56 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m928dUt3003694 ; Thu, 2 Oct 2008 10:39:30 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m928dTeu085188 ; Thu, 2 Oct 2008 10:39:29 +0200 (CEST) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id m928dThm056412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 2 Oct 2008 10:39:29 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Pedro Alves'" , References: <005401c923c0$be5ae250$3b10a6f0$@u-strasbg.fr> <200810011909.10343.pedro@codesourcery.com> In-Reply-To: <200810011909.10343.pedro@codesourcery.com> Subject: RE: [RFC] fix win32-nat failure Date: Thu, 02 Oct 2008 08:41:00 -0000 Message-ID: <009a01c9246a$64ece5b0$2ec6b110$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::152]); Thu, 02 Oct 2008 10:39:30 +0200 (CEST) X-Virus-Status: Clean 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: 2008-10/txt/msg00044.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Wednesday, October 01, 2008 8:09 PM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [RFC] fix win32-nat failure >=20 > On Wednesday 01 October 2008 13:25:08, Pierre Muller wrote: >=20 > > Current GDB head has a problem with win32-nat: > > > > When starting ./gdb ./gdb > > (gdb) run > > Starting program: /usr/local/src/gdbcvs/build-bare/gdb/gdb.exe ./gdb > > ../../purecvs/gdb/inferior.c:41: internal-error: current_inferior: > Assertion > > `inf' failed. >=20 > Ah, I know why I didn't see this happening. When running GDB under > GDB itself, GDB considers that it doesn't have a terminal at all, so > this code path isn't exercised. Maybe this applies to the testsuite > as well. :-/ Well, in fact, I don't understand this statement, after reading it, I suspected that this had to do with the fact that I use a lot the 'set new-console on' option, but even without this I still get the same assertion failed message, so I don't understand why you did not also get it. =20 > > I was able to fix this by setting inferior_ptid before > terminal_inferior was > > called, > > but I did this using also the ThreadId available when starting with > > CreateProcess. > > But there is no thread number available for processes to which we > attach, > > thus I simply passed zero in that case... >=20 > > I don't know, maybe the correct fix is to only set inferior_ptid > > to ptid_build(pid, 0, 0) >=20 > Yes, you don't need the tid at this point even when creating instead > of attaching. A smaller change would be something like this: >=20 > + inferior_ptid =3D pid_to_ptid (pid); >=20 > terminal_init_inferior_with_pgrp (pid); >=20 > Perhaps also adding a comment saying something like: >=20 > /* Make the new process the current inferior, so terminal handling > can rely on it. When attaching, we don't know about any thread > id here, but that's OK --- nothing should be referencing the > current thread until we report an event out of win32_wait. */ >=20 > Do you want to give it a try and confirm on your end? OK, let me try this simpler patch out, I will send a RFA if that works OK for me. Pierre Muller Pascal language support maintainer for GDB