From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13315 invoked by alias); 8 Apr 2014 02:44:42 -0000 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 Received: (qmail 13301 invoked by uid 89); 8 Apr 2014 02:44:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Apr 2014 02:44:37 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N3O00900XM3O900@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Tue, 08 Apr 2014 05:44:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3O0094MYAB7P80@a-mtaout20.012.net.il>; Tue, 08 Apr 2014 05:44:35 +0300 (IDT) Date: Tue, 08 Apr 2014 02:44:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <20140407213913.GE4250@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ha647d6d.fsf@gnu.org> References: <83pplja2h9.fsf@gnu.org> <20140318165413.GE4282@adacore.com> <834n2kztfw.fsf@gnu.org> <53358C37.9050907@redhat.com> <83a9cafcpz.fsf@gnu.org> <5335B619.6040605@redhat.com> <8361myfa6l.fsf@gnu.org> <83ioqucrkw.fsf@gnu.org> <5342DBBC.4090500@redhat.com> <83lhvh6lqi.fsf@gnu.org> <20140407213913.GE4250@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00090.txt.bz2 > Date: Mon, 7 Apr 2014 14:39:13 -0700 > From: Joel Brobecker > Cc: Pedro Alves , gdb-patches@sourceware.org > > > But the warnings I was talking about are output with OUTMSG, which > > doesn't depend on debug_threads. Here's an example: > > > > static void > > suspend_one_thread (struct inferior_list_entry *entry) > > { > > struct thread_info *thread = (struct thread_info *) entry; > > win32_thread_info *th = inferior_target_data (thread); > > > > if (!th->suspended) > > { > > if (SuspendThread (th->h) == (DWORD) -1) > > { > > DWORD err = GetLastError (); > > OUTMSG (("warning: SuspendThread failed in suspend_one_thread, " > > "(error %d): %s\n", (int) err, strwinerror (err))); > > > > Did I miss something? > > This code not going to be used at all if you debug through GDBserver > (it's the code in remote.c that does). Sorry, I don't understand: remote.c is not specific to Windows, so it cannot include any Windows-specific calls like SuspendThread. > But if the GDBserver code does the same thing as windows-nat in > terms of inferior management, it might trigger the same error and > output them on GDBserver's stdout/stderr if --debug is enabled. Again, I don't see where --debug comes into play here. Can you tell me what am I missing? > Usually, we try to keep the GDB and GDBserver code in sync, and that > means that we fix a problem in inferior management, it's a good bet > that the same problem exists on both sides. As I said, I don't see the same problem in the server. > I might be able to take a look sometime next week. I think the issue > we'll have is with testing, since the problem is not necessarily always > reproduceable in Eli's scenario, and he would need to debug repeatedly > with GDBserver in order to gain a good level of confidence that the > problem is gone for good. I can reproduce it with some effort, so verifying a fix is not a problem.