public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@redhat.com
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] Extended-remote follow-exec
Date: Fri, 11 Sep 2015 18:33:00 -0000	[thread overview]
Message-ID: <94585166dfea8232c248044f9f4b1c217dc4ac2e@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 94585166dfea8232c248044f9f4b1c217dc4ac2e ***

Author: Don Breazeal <donb@codesourcery.com>
Branch: master
Commit: 94585166dfea8232c248044f9f4b1c217dc4ac2e

Extended-remote follow-exec

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
----------------
Exec events are enabled via ptrace options.

When an exec event is detected by gdbserver, the existing process
data, along with all its associated lwp and thread data, is deleted
and replaced by data for a new single-threaded process.  The new
process data is initialized with the appropriate parts of the state
of the execing process.  This approach takes care of several potential
pitfalls, including:

 * deleting the data for an execing non-leader thread before any
   wait/sigsuspend occurs
 * correctly initializing the architecture of the execed process

We then report the exec event using a new RSP stop reason, "exec".

When GDB receives an "exec" event, it saves the status in the event
structure's target_waitstatus field, like what is done for remote fork
events.  Because the original and execed programs may have different
architectures, we skip parsing the section of the stop reply packet
that contains register data.  The register data will be retrieved
later after the inferior's architecture has been set up by
infrun.c:follow_exec.

At that point the exec event is handled by the existing event handling
in GDB.  However, a few changes were necessary so that
infrun.c:follow_exec could accommodate the remote target.

 * Where follow-exec-mode "new" is handled, we now call
   add_inferior_with_spaces instead of add_inferior with separate calls
   to set up the program and address spaces.  The motivation for this
   is that add_inferior_with_spaces also sets up the initial architecture
   for the inferior, which is needed later by target_find_description
   when it calls target_gdbarch.

 * We call a new target function, target_follow_exec.  This function
   allows us to store the execd_pathname in the inferior, instead of
   using the static string remote_exec_file from remote.c.  The static
   string didn't work for follow-exec-mode "new", since once you switched
   to the execed program, the original remote exec-file was lost.  The
   execd_pathname is now stored in the inferior's program space as a
   REGISTRY field.  All of the requisite mechanisms for this are
   defined in remote.c.

gdb/gdbserver/ChangeLog:

	* linux-low.c (linux_mourn): Static declaration.
	(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.  Make event_lwp argument a
	pointer-to-a-pointer.
	(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.
	Pass child lwp pointer by reference to handle_extended_wait.
	(linux_wait_for_event_filtered): Update comment.
	(linux_wait_1): Prevent clobbering exec event status.
	(linux_supports_exec_events): New function.
	(linux_target_ops) <supports_exec_events>: Initialize new member.
	* lynx-low.c (lynx_target_ops) <supports_exec_events>: Initialize
	new member.
	* remote-utils.c (prepare_resume_reply): New stop reason 'exec'.
	* server.c (report_exec_events): New global variable.
	(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.
	(target_supports_exec_events): New macro.
	* win32-low.c (win32_target_ops) <supports_exec_events>:
	Initialize new member.

gdb/ChangeLog:

	* infrun.c (follow_exec): Use process-style ptid for
	exec message.  Call add_inferior_with_spaces and
	target_follow_exec.
	* nat/linux-ptrace.c (linux_supports_traceexec): New function.
	* nat/linux-ptrace.h (linux_supports_traceexec): Declare.
	* remote.c (remote_pspace_data): New static variable.
	(remote_pspace_data_cleanup): New function.
	(get_remote_exec_file): New function.
	(set_remote_exec_file_1): New function.
	(set_remote_exec_file): New function.
	(show_remote_exec_file): New function.
	(remote_exec_file): Delete static variable.
	(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_follow_exec): New function.
	(remote_parse_stop_reply): Handle 'exec' stop reason.
	(extended_remote_run, extended_remote_create_inferior): Call
	get_remote_exec_file and set_remote_exec_file_1.
	(init_extended_remote_ops) <to_follow_exec>: Initialize new
	member.
	(_initialize_remote): Call
	register_program_space_data_with_cleanup.  Call
	add_packet_config_cmd for remote exec-events feature.
	Modify call to add_setshow_string_noescape_cmd for exec-file
	to use new functions set_remote_exec_file and
	show_remote_exec_file.
	* target-debug.h, target-delegates.c: Regenerated.
	* target.c (target_follow_exec): New function.
	* target.h (struct target_ops) <to_follow_exec>: New member.
	(target_follow_exec): Declare new function.


             reply	other threads:[~2015-09-11 18:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 18:33 sergiodj+buildbot [this message]
2015-09-11 18:33 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot
2015-09-11 18:33 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2015-09-11 18:41 ` Failures on Fedora-i686, " sergiodj+buildbot
2015-09-11 18:41 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2015-09-11 18:42 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2015-09-11 18:52 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-09-11 18:52 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-09-11 18:54 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-09-11 18:55 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2015-09-11 19:09 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot
2015-09-11 19:12 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2015-09-11 19:28 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj+buildbot
2015-09-11 20:27 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-09-11 20:48 ` Failures on Debian-i686, " sergiodj+buildbot
2015-09-11 21:02 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-09-11 21:19 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot
2015-09-11 21:22 ` Failures on Fedora-ppc64le-m64, " sergiodj+buildbot
2015-09-11 21:50 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot
2015-09-12  0:43 ` Failures on Debian-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-09-12 17:11 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94585166dfea8232c248044f9f4b1c217dc4ac2e@gdb-build \
    --to=sergiodj+buildbot@redhat.com \
    --cc=gdb-testers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).