From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24144 invoked by alias); 8 Apr 2014 04:23:37 -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 24121 invoked by uid 89); 8 Apr 2014 04:23:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Apr 2014 04:23:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 75C9C1160FF; Tue, 8 Apr 2014 00:23:30 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zWO0uD9NBZab; Tue, 8 Apr 2014 00:23:30 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 389CF1160AF; Tue, 8 Apr 2014 00:23:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 92A80E0BF1; Mon, 7 Apr 2014 21:23:31 -0700 (PDT) Date: Tue, 08 Apr 2014 04:23:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: palves@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue Message-ID: <20140408042331.GF4250@adacore.com> References: <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> <83ha647d6d.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ha647d6d.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00091.txt.bz2 > Sorry, I don't understand: remote.c is not specific to Windows, so it > cannot include any Windows-specific calls like SuspendThread. I think the easiest is probably for you to take a look at the code in gdb/gdbserver/win32-low.c. This file actually also has a routine called thread_rec, and generally speaking, the code in gdb/*-nat.c and the corresponding gdb/gdbserver/*-low.c can (and probably should) be very similar - at least until we can factorize that code and reuse the gdbserver code in GDB. The reason I was mentioning remote.c is because, when you use GDBserver, GDBserver does all the inferior control for GDB. It's like a mini debugger, except that it does not have a user interface, only a serial interface that GDB can used to communicate with it and send it orders such as read or write memory, next/step operations, continue, kill, etc. So, even if you are using a Windows native debugger, as soon as you type the "target remote [...]" command, the windows-nat target gets swapped out in favor of the "remote" target, which then delegates the inferior control to the agent (gdbserver). The code that does that delegation is in remote.c. So, to try to reproduce with GDBserver, you'd have to do the following. In one terminal, start your program with gdbserver. For instance: % gdbserver --debug :4567 YOUR_PROGRAM It'll write a message saying that the program has been started, and that it's now waiting for a connection on port 4567. The --debug switch is not normally necessary, but allows us to turn warnings on, which then allows us to determine whether or not we reproduced the problem in GDB. Next, start GDB in a second terminal, and connect to it via: % gdb YOUR_PROGRAM (gdb) target remote :4567 The "target remote [...]" command replaces the "run" command. >From there, everything else should be the same as the reproducer you have for the case where GDBserver isn't involved. And instead of seeing the warning in the GDB console, you would see it in the terminal where gdbserver was started. The idea for solving the issue on the gdbserver side would be to apply the very same sort of change you applied to windows-nat, but to win32-low, essentially keeping the implementations in sync. -- Joel