Re: [PATCH 2/3] gdbserver/Windows: Fix "no program to debug" error

[Pedro Alves <palves@redhat.com>]

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