From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83453 invoked by alias); 9 May 2018 23:17:25 -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 83440 invoked by uid 89); 9 May 2018 23:17:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Share, killing X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 May 2018 23:17:24 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 86FBC1147C5; Wed, 9 May 2018 23:17:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 14F7C2022EEE; Wed, 9 May 2018 23:17:21 +0000 (UTC) Subject: Re: [PATCH 2/3] gdbserver/Windows: Fix "no program to debug" error To: Joel Brobecker , gdb-patches@sourceware.org References: <1525458603-33351-1-git-send-email-brobecker@adacore.com> <1525458603-33351-3-git-send-email-brobecker@adacore.com> From: Pedro Alves Message-ID: <524b34ea-13aa-130f-a07c-da661b350873@redhat.com> Date: Thu, 10 May 2018 00:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1525458603-33351-3-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00228.txt.bz2 On 05/04/2018 07:30 PM, Joel Brobecker wrote: > Trying to start a program with GDBserver on Windows yields > the following error: > > $ gdbserver.exe --once :4444 simple_main.exe > Killing process(es): 5008 > No program to debug > Exiting > > The error itself comes from the following code shortly after > create_inferior gets called (in server.c::main): > > /* Wait till we are at first instruction in program. */ > create_inferior (program_path.get (), program_args); > [...] > > if (last_status.kind == TARGET_WAITKIND_EXITED > || last_status.kind == TARGET_WAITKIND_SIGNALLED) > was_running = 0; > else > was_running = 1; > > if (!was_running && !multi_mode) > error ("No program to debug"); > > What happens is that the "last_status" global starts initialized > as zeroes, which means last_status.kind == TARGET_WAITKIND_EXITED, > and we expect create_inferior to be waiting for the inferior to > start until reaching the SIGTRAP, and to set the "last_status" > global to match that last event we received. > > I suspect this is an unintended side-effect of the following change... > > commit 2090129c36c7e582943b7d300968d19b46160d84 > Date: Thu Dec 22 21:11:11 2016 -0500 > Subject: Share fork_inferior et al with gdbserver > > ... which removes some code in server.c that was responsible for > starting the inferior in a functin that was named start_inferior, > and looked like this: > > signal_pid = create_inferior (new_argv[0], &new_argv[0]); > [...] > /* Wait till we are at 1st instruction in program, return new pid > (assuming success). */ > last_ptid = mywait (pid_to_ptid (signal_pid), &last_status, 0, 0); > > The code has been transitioned to using fork_inferior, but sadly, > only for the targets that support it. On Windows, the calls to wait > setting "last_status" simply disappeared. > > This patch adds it back in the Windows-specific implementation of > create_inferior. > > gdb/gdbserver/ChangeLog: > > * win32-low.c (win32_create_inferior): Add call to my_wait > setting last_status global. > --- > gdb/gdbserver/win32-low.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gdb/gdbserver/win32-low.c b/gdb/gdbserver/win32-low.c > index db5dd49..7ed5fc5 100644 > --- a/gdb/gdbserver/win32-low.c > +++ b/gdb/gdbserver/win32-low.c > @@ -704,6 +704,10 @@ win32_create_inferior (const char *program, > > do_initial_child_stuff (pi.hProcess, pi.dwProcessId, 0); > > + /* Wait till we are at 1st instruction in program, return new pid > + (assuming success). */ > + last_ptid = win32_wait (pid_to_ptid (current_process_id), &last_status, 0); > + > return current_process_id; > } Ah, I was confused about how this actually works, since do_initial_child_stuff already waits until we're at the 1st instruction of the program: /* Flush all currently pending debug events (thread and dll list) up to the initial breakpoint. */ while (1) { but after staring at this for a bit, I remembered/realized the loop leaves the status pending in the 'cached_status' global. So the patch LGTM as is. Thanks, Pedro Alves