[v2,1/5] Extended-remote follow exec

This is an updated patch that implements support for multi-arch exec
(e.g. a 64-bit executable execs a 32-bit executable).  The changes
from the previous version reinitialize the target architecture in both
gdbserver and gdb when an exec event is first reported.  The architecture
re-init is done unconditionally for simplicity's sake, rather than
only doing it if the architecture of the new executable is different
from the existing target architecture.

In addition we make sure that the exec event message uses a process-style
ptid, so as to match the message emitted in the native case.  This is the
same change that was done for fork event messages.

Updated commit message, ChangeLog, and patch follow.

Thanks
--Don

----
This patch implements support for exec events on extended-remote Linux
targets.  Follow-exec-mode and rerun behave as expected.  Catchpoints and
test updates are implemented in subsequent patches.

This patch was derived from a patch posted last October:
https://sourceware.org/ml/gdb-patches/2014-10/msg00877.html.
It was originally based on some work done by Luis Machado in 2013.

IMPLEMENTATION
----------------
I. Basic Exec Events
   Basic 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 and set
      event status flags.

   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.

II. Multi-Arch Support
   We re-use the lwp, thread, and process data structures of the original
   execing inferior for the exec'd program.  However, we don't know if the
   architecture of the new executable is the same as that of the original
   program.  In order to ensure that the architecture is updated correctly,
   we unconditionally update it after every exec event.  In gdbserver, we
   call a new wrapper function that call the target's arch_update function
   for the specified thread.  We also update the previously-invalidated
   register cache, now that we know we will access the registers correctly
   with the updated architecture, and we clear the process's r_debug
   pointer to force a reset of the address of the solib event hook for the
   (possibly) new architecture.  The old solib breakpoint itself is
   deleted in infrun.c:follow_exec.

         linux_arch_setup_thread (event_thr);
	 event_lwp->stop_pc = get_pc (event_lwp);
	 proc = get_thread_process (event_thr);
	 proc->priv->r_debug = 0;

   We also need to update the target architecture on the GDB side.  This
   must be done before it has a chance to try to access the registers, so
   we do this in remote.c:remote_parse_stop_reply as soon as we see the
   "exec" stop reason.

            else if (strncmp (p, "exec", p1 - p) == 0)
	      {
	      ---snip---
		target_clear_description ();
		exec_file_attach (remote_exec_file, 0);

III. Multi-Thread Support
   Support for exec events in multi-threaded programs required some
   additional work.  When exec is called, the Linux kernel destroys all of
   the threads except the execing one.  If the execing thread was not the
   thread group leader, the kernel resets the execing thread's tid to the
   tgid, and no exit notification is sent for the execing thread -- from
   the ptracer's perspective, it appears as though the execing thread just
   vanishes.

   The non-leader exec leaves gdbserver with one or more of several
   potential scenarios which require it to bring its thread lists (e.g.
   struct thread_info, struct lwp_info) in sync with reality.

   - The leader thread exited before the exec event was reported, and
     the execing thread cannot re-use its data structures.

     In this case gdbserver must recognize that an exec event occurred and
     there are no thread structures for the leader thread, so it must add
     new structures to the lists for the 'new' leader thread.

  if (WIFSTOPPED (wstat) && (child == NULL) && (WSTOPSIG (wstat) == SIGTRAP)
      && (linux_ptrace_get_extended_event (wstat) == PTRACE_EVENT_EXEC))
    {
      ptid_t child_ptid;

      /* A multi-thread exec after we had seen the leader exiting.  */
      if (debug_threads)
	{
	  debug_printf ("LLW: Re-adding thread group leader LWP %d"
			"after exec.\n", lwpid);
	}

      child_ptid = ptid_build (lwpid, lwpid, 0);
      child = add_lwp (child_ptid);
      child->stopped = 1;
      current_thread = child->thread;
    }

   - The execing thread can re-use the previous leader thread's data
     structures, and the old data structures used for the execing thread
     prior to the exec are left with a running status and no actual thread
     associated with it.  There are two major issues to address because of
     this.

     First, when a non-leader execing thread re-uses the previous leader's
     thread_info structure, it inherits the old thread's register cache.
     If this is left as-is it will eventually be flushed to the target,
     clobbering the valid register values with those from the old thread.
     So when an EXEC event occurs we always invalidate the register cache.
     Note that we can't call regcache_invalidate, since that flushes the
     cache to the target, clobbering all the registers.

  else if (event == PTRACE_EVENT_EXEC && report_exec_events)
    {
      struct regcache *regcache;
      ---snip snip---
      regcache = (struct regcache *) inferior_regcache_data (event_thr);
      free_register_cache (regcache);
      set_inferior_regcache_data (event_thr, NULL);

     The second issue is that gdbserver must clean up any stale thread/lwp
     structures before it eventually tries to stop all the threads.  If it
     doesn't, it will hang in sigsuspend, waiting for an event from a
     non-existent thread.

     For all-stop mode We do this by checking the return value from
     kill_lwp in send_sigstop, eventually called after calling
     stop_all_lwps, which is used to stop the threads in all-stop mode.  If
     kill_lwp returns an error and errno is ESRCH, we know that the lwp
     with that pid is gone, and we delete the associated data structures.

-  kill_lwp (pid, SIGSTOP);
+  errno = 0;
+  ret = kill_lwp (pid, SIGSTOP);
+  if (ret == -1 && errno == ESRCH)
+    {
+      /* If the kill fails with "No such process", on GNU/Linux we know
+	 that the LWP has vanished - it is not a zombie, it is gone.
+	 This is because a thread that was not the thread group leader
+	 called exec and took over the leader's lwp.  */
+      delete_lwp (lwp);
+      set_desired_thread (0);

     In the same case in non-stop mode, we aren't going to stop all the
     lwps.  In order to utilize the same mechanism used in all-stop mode,
     we call stop_all_lwps/unstop_all_lwps in succession, just to check for
     ESRCH errors and to delete any stale thread structures.

      if (non_stop && stopping_threads == NOT_STOPPING_THREADS)
	{
	  /* In non-stop mode, make sure we delete the lwp entry for a
	     non-leader exec'ing thread, which will have vanished.  We
	     do this by sending a signal to all the other threads in the
	     lwp list, deleting any that are not found.  Note that in
	     all-stop mode this will happen when we stop all the threads.  */
	  stop_all_lwps (0, event_lwp);
	  unstop_all_lwps (0, event_lwp);
	}

     Note that the native implementation uses a different mechanism for
     identifying the stale data structure scenario.  It determines that the
     execing thread has "vanished" by calling waitpid(PID) and checking for
     a return value of ECHILD, which 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

     so we use the send_sigstop method described above instead.

TESTING
--------
x86_64 GNU/Linux for native, native-gdbserver, and
native-extended-gdbserver targets.  Most of the exec-related tests fail
due to the lack of catchpoints and extended-remote support in the tests,
both of which are resolved in subsequent patches in this patchset.

gdb/gdbserver/
2015-07-30  Don Breazeal  <donb@codesourcery.com>
	    Luis Machado  <lgustavo@codesourcery.com>

	* linux-low.c (linux_arch_setup): Move in front of
	handle_extended_wait.
	(linux_arch_setup_thread): New function.
	(handle_extended_wait): Handle exec events.  Call
	linux_arch_setup_thread.
	(check_zombie_leaders): Do not check stopped threads.
	(linux_low_ptrace_options): Add PTRACE_O_TRACEEXEC.
	(linux_low_filter_event): Add lwp and thread for exec'ing
	non-leader thread if leader thread has been deleted.
	Refactor code into linux_arch_setup_thread and call it.
	(linux_wait_for_event_filtered): Update comment.
	(extended_event_reported): Add TARGET_WAITKIND_EXECD.
	(linux_wait_1): Prevent clobbering extended event status.
	(send_sigstop): Check return from kill_lwp and delete non-
	existent lwps.
	(linux_supports_exec_events): New function.
	* lynx-low.c (lynx_target_ops) <supports_exec_events>:
	Initialize new member.
	* remote-utils.c (prepare_resume_reply): New stop reason 'exec'.
	* server.c (handle_query): Handle qSupported query for
	exec-events feature.
	(captured_main): Initialize report_exec_events.
	* server.h (report_exec_events): Declare new global variable.
	* target.h (struct target_ops) <supports_exec_events>: New
	member.
	* win32-low.c (win32_target_ops) <supports_exec_events>:
	Initialize new member.

gdb/
2015-07-30  Don Breazeal  <donb@codesourcery.com>
	    Luis Machado  <lgustavo@codesourcery.com>

	* infrun.c (follow_exec): Use process-style ptid for
	exec message.
	* nat/linux-ptrace.c (linux_supports_traceexec): New function.
	* nat/linux-ptrace.h (linux_supports_traceexec): Declare.
	* remote.c (anonymous enum) <PACKET_exec_event_feature> New
	enumeration constant.
	(remote_protocol_features): Add entry for exec-events feature.
	(remote_query_supported): Add client side of qSupported query
	for exec-events feature.
	(remote_parse_stop_reply): Handle 'exec' stop reason.
	(_initialize_remote): Call add_packet_config_cmd for remote
	exec-events feature.

---
 gdb/gdbserver/linux-low.c    | 161 +++++++++++++++++++++++++++++++++++++------
 gdb/gdbserver/lynx-low.c     |   1 +
 gdb/gdbserver/remote-utils.c |  20 ++++++
 gdb/gdbserver/server.c       |  11 +++
 gdb/gdbserver/server.h       |   1 +
 gdb/gdbserver/target.h       |   7 ++
 gdb/gdbserver/win32-low.c    |   1 +
 gdb/infrun.c                 |   4 +-
 gdb/nat/linux-ptrace.c       |  13 +++-
 gdb/nat/linux-ptrace.h       |   1 +
 gdb/remote.c                 |  36 ++++++++++
 11 files changed, 230 insertions(+), 26 deletions(-)

[v2,1/5] Extended-remote follow exec

Commit Message

Comments

Patch