bogus extra code in gdbserver detach command support?

Pedro Alves pedro@codesourcery.com
Tue Apr 26 10:37:00 GMT 2011


On Monday 25 April 2011 22:57:58, Doug Evans wrote:
> Hi.
> 
> Under what circumstances does this code in server.c actually do something?
> 
> 	      /* If we are attached, then we can exit.  Otherwise, we
> 		 need to hang around doing nothing, until the child is
> 		 gone.  */
> 	      for_each_inferior (&all_processes,
> 				 join_inferiors_callback);
> 
> This is for the 'D' packet.
> AIUI, this code will already have emptied all_processes:
> 
>       if (detach_inferior (pid) != 0)
> 	write_enn (own_buf);

Hmm, looks like I broke this with the multi-process changes.  If you
look back at, e.g., gdb 6.8, the join backend implementations would work
because they only relied on the signal_pid global, not any process
structure:

static void
linux_join (void)
{
  extern unsigned long signal_pid;
  int status, ret;

  do {
    ret = waitpid (signal_pid, &status, 0);
    if (WIFEXITED (status) || WIFSIGNALED (status))
      break;
  } while (ret != -1 || errno != ECHILD);
}

/* Wait for inferiors to end.  */
static void
win32_join (void)
{
  extern unsigned long signal_pid;

  HANDLE h = OpenProcess (PROCESS_ALL_ACCESS, FALSE, signal_pid);
  if (h != NULL)
    {
      WaitForSingleObject (h, INFINITE);
      CloseHandle (h);
    }
}


Looks like removing the:

  struct process_info *process;

  process = find_process_pid (pid);
  if (process == NULL)
    return;

bit from linux_join, and call join_inferior
directly on the detachee's pid from server.c
would restore the old behavior.

> 
> Or can multiprocess debugging be used without the extended remote protocol?

Nope.

-- 
Pedro Alves



More information about the Gdb mailing list