From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24169 invoked by alias); 1 May 2009 12:57:41 -0000 Received: (qmail 24160 invoked by uid 22791); 1 May 2009 12:57:40 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 May 2009 12:57:33 +0000 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KIY00500UN37Y00@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Fri, 01 May 2009 15:57:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.230.216]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIY00A6XUNTJ1Z0@i_mtaout3.012.net.il>; Fri, 01 May 2009 15:57:30 +0300 (IDT) Date: Fri, 01 May 2009 12:57:00 -0000 From: Eli Zaretskii Subject: Re: [djgpp/commit] Fix go32_pid_to_str and go32_thread_alive In-reply-to: <200905011118.51917.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83y6thc75n.fsf@gnu.org> References: <834ow5dypg.fsf@gnu.org> <200905011118.51917.pedro@codesourcery.com> 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: 2009-05/txt/msg00015.txt.bz2 > From: Pedro Alves > Date: Fri, 1 May 2009 11:18:51 +0100 > > On Friday 01 May 2009 09:17:15, Eli Zaretskii wrote: > > > 2009-05-01 Eli Zaretskii > > > > * go32-nat.c (go32_pid_to_str): Call normal_pid_to_str instead of > > printing a bogus "Thread
". > > I thought that the inferior's PID on DJGPP is always the > fake SOMEPID (42) True. > an internal implementation detail, that we'd > never want to show to the user, but, normal_pid_to_str will > print "process 42" here. Isn't that bogus as well? It is, to some degree. But IMO talking about threads in an environment that doesn't support threads is a greater lie, so to say ;-) I wanted the output to be more like when one debugs a single-threaded program on Unix, because when I first saw that "Thread
" displayed by "set debug infrun 1", I thought there's some bug somewhere whereby GDB thinks it's debugging a multithreaded program. DJGPP users are already used to see 42 popping here and there; e.g., that's what getuid and getgid return for the only user and group they support. I briefly considered a possibility to add a function to more faithfully fake the PID of the inferior (DJGPP's version of getpid simply returns the current BIOS clock tick counter, so I could fetch that from GDB), but eventually I decided it wasn't worth the hassle. > > (go32_thread_alive): Don't return 1 for null_ptid. > > Interesting. This may be masking some other problem. How > did you get here with inferior_ptid == null_ptid? I didn't. It just seemed unclean to me to return 1 for null_ptid, when just a little ways above, in go32_stop, we assign it when we delete the single alive thread. > AFAICS, when the inferior exits or is killed, the go32_ops target is > unpushed. I have no doubt that you are right, but at some future point this method could potentially be called in some other context. If you think my change may mask other problems, now or in the future, I'm okay with adding some appropriate gdb_assert here. Thanks for the feedback.