[binutils-gdb] [lynxos] gdbserver hangs when killing inferior from GDB

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT 4abd5ed2221c826bcb843794286777452de5c50b ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: master
Commit: 4abd5ed2221c826bcb843794286777452de5c50b

[lynxos] gdbserver hangs when killing inferior from GDB

With any program under GDBserver control on LynxOS, killing
the program from the debugger (using the "kill" command) causes
GDBserver to properly kill the inferior but GDBserver then hangs.

This change of behavior occured after the following change was
applied:

    commit f0ea042932e6922c90df3fd0001497d287b97677
    Date:   Mon Nov 30 16:05:27 2015 +0000
    Subject: gdbserver: don't exit until GDB disconnects

One of the changes introduced by the commit above is that
process_serial_event no longer calls exit after handling
the vKill packet. Instead, what happens is that we wait
until captured_main finds that we no longer have any inferior
to debug, at which point it throws_quit. This (normal) exception
is then expected to propagate all the way to the exception handle
in function "main", which calls exit.

However, before the exception gets propagated, the cleanups
are first executed, and one of the cleanups in question is
detach_or_kill_for_exit_cleanup, which was put in place by
captured_main. detach_or_kill_for_exit_cleanup is basically
a wrapper around detach_or_kill_for_exit, which iterates
over all inferiors, and kills them all.

In our case, we have only one inferior, which we have already
killed during the handling for the "vKill" packet. Unfortunately,
we did not properly clean our internal data for that inferior up,
and so detach_or_kill_for_exit thinks that we still have one inferior,
and therefore tries to kill it. This results in lynx_kill being
called, doing the following:

    lynx_ptrace (PTRACE_KILL, ptid, 0, 0, 0);
    lynx_wait (ptid, &status, 0);
    the_target->mourn (process);

The hang is caused by the call to lynx_wait, which waits for
an event from a process which does not exist...

This patch fixes the issue by enhancing lynx_mourn to clean
the threads and process list up.

gdb/gdbserver/ChangeLog:

        * lynx-low.c (lynx_delete_thread_callback): New function.
        (lynx_mourn): Properly delete our process and all of its
        threads.  Remove call to clear_inferiors.