[2/4,REPOST] Remote Linux ptrace exec events

From: Don Breazeal <don_breazeal@mentor.com>

  From: Don Breazeal <don_breazeal@mentor.com>

[Reposting to eliminate unexpected attachment type.]

This patch implements support for exec events in gdbserver on linux, in
multiprocess mode (target extended-remote).  Follow-exec-mode and rerun
behave as expected.  Catchpoints for exec are not yet implemented since it
will be easier to implement catchpoints for fork, vfork, and exec all at
the same time.

TESTING
---------
The patch was tested on GNU/Linux x86_64 with --target_board set to
native-gdbserver and native-extended-gdbserver, as well as testing native
GDB.  The test results for native-gdbserver were unchanged.  Thirteen tests
that used to fail for native-extended-gdbserver on Linux pass with this
patch, and the non-ldr-exc-*.exp tests all pass in non-stop mode and
extended-remote.  There are several failures in the new non-ldr-exc-*.exp
tests in non-stop mode with native GDB.

One caveat: when an exec is detected, gdbserver emits a couple of warnings:
    gdbserver: unexpected r_debug version 0
    gdbserver: unexpected r_debug version 0
However, debugging of shared libraries that are loaded by the exec'd
program works just fine.  These messages may be caused by gdbserver making
an attempt to initialize the solib hook before the r_debug structure has
been initialized.  I intend to follow up in a subsequent patch.

IMPLEMENTATION
----------------
Support for exec events in single-threaded programs was a fairly
straightforward replication of the implementation in native GDB:
   1) Enable exec events via ptrace options.
   2) Add support for handling the exec events to the handle_extended_wait
      and linux_wait_for_event_filtered.  Detect the exec event, then
      find and save the pathname of the executable file being exec'd.
   3) Implement an additional "stop reason", "exec", in the RSP stop reply
      packet "T".
Existing GDB code takes care of handling the exec event on the host side
without modification.

Support for exec events in multi-threaded programs required some additional
work that required a couple of significant changes to existing code.  In a
nutshell, the changes are to:
   4) Use the PTRACE_EVENT_EXIT extended event to handle thread exit,
      while not exposing any change in exit handling to the user.  The
      rationale for this is discussed in the "patch 0" email of this
      series.
   5) Recognize when the exec'ing thread has vanished (become the thread
      group leader) in send_sigstop.  Native GDB does this differently.

Regarding items 4 & 5: Recall that when a non-leader thread exec's, all the
other threads are terminated and the exec'ing thread changes its thread id
to that of the old leader (the process id) as part of the exec.  There is
no event reported for the "exit" of the exec'ing thread; it appears to have
vanished.  The original thread group leader can't be reaped until all the
other threads have been reaped, and some way of determining that it has
exited is required in order to update the lwp list (#4 above). Also, some
mechanism for deleting the lwp entry corresponding to the exec'ing thread
is needed (#5 above).

The rationale for #4 is that in my testing I ran into a race condition in
the mechanism that's intended to detect when a thread group leader has
exited, check_zombie_leaders.  The race occurred when there were only two
threads in the program.  In this case the leader thread passes through a
very brief zombie state before being replaced by the exec'ing thread as
the thread group leader.  This state transition is asynchronous, with no
dependency on anything gdbserver does.  Using PTRACE_EVENT_EXIT ensures
that the leader exit will be detected.  I can provide a more detailed
explanation or the race, but I didn't want to be too long-winded here.

Regarding item #5, determining that the exec'ing thread has "vanished", In
native GDB this is done by calling waitpid(PID), and if it returns ECHILD
it means that the thread is gone.  We don't want to use waitpid(PID) in
gdbserver, based on the discussion in
https://www.sourceware.org/ml/gdb-patches/2014-02/msg00828.html. An
alternative is to send a signal to each thread and look for an ESRCH (No
such process) error.  In all-stop mode this can be done in the normal
course of events, since when gdbserver reports an exec event it stops all
the other threads with a SIGSTOP.  In non-stop mode, when an exec event has
been detected, we can call stop_all_lwps/unstop_all_lwps to accomplish the
same thing.

gdb/
2014-04-02  Don Breazeal  <donb@codesourcery.com>

	* common/linux-ptrace.c (linux_test_for_tracefork)
	[GDBSERVER]: Add exec tracing to ptrace options if OS supports
	it.
	* remote.c (remote_parse_stop_reply): Support new RSP stop
	reply reason 'exec'.

gdbserver/
2014-04-02  Don Breazeal  <donb@codesourcery.com>

	* gdb/gdbserver/linux-low.c (linux_child_pid_to_exec_file): New
	function.
	(handle_extended_wait): Add support for PTRACE_EVENT_EXEC.
	(check_zombie_leaders): Update comment.
	(linux_low_filter_event): Add support for PTRACE_EVENT_EXEC.
	(linux_wait_for_event_filtered): Update comment.
	(extended_event_reported): New function.
	(send_sigstop): Delete lwp on 'No such process' error and
	reset current_inferior.
	* gdb/gdbserver/linux-low.h (struct lwp_info): New member
	'waitstatus'.
	* gdb/gdbserver/remote-utils.c (prepare_resume_reply): Support
	new RSP stop reply reason 'exec'.

---
 gdb/common/linux-ptrace.c    |    7 +-
 gdb/gdbserver/linux-low.c    |  175 ++++++++++++++++++++++++++++++++++++++----
 gdb/gdbserver/linux-low.h    |    5 +
 gdb/gdbserver/remote-utils.c |   28 +++++++-
 gdb/remote.c                 |   27 ++++++-
 5 files changed, 222 insertions(+), 20 deletions(-)

[2/4,REPOST] Remote Linux ptrace exec events

Commit Message

Comments

Patch