This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 0/4] Exec events in gdbserver on Linux


This patch implements support for exec events in gdbserver on GNU/Linux.
This is a step towards the "follow fork/exec" item in the local/remote
debugging feature parity project:
(https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity).  Luis had
started work on this last year, and handed it off to me at the end of
January.  (BTW, thanks to Luis for his advice on this, although any
problems with this patch are entirely mine.)

Follow-exec-mode and rerun behave as expected in multiprocess mode 
(target extended-remote), where follow-exec-mode maintains the 
specified inferiors and rerun runs the last executable file to be 
exec'd.  Catchpoints for exec are not implemented in this patch series,
since this will be easier to do once fork and vfork events are also
supported.

- Patch 1/4 implements support for the extended ptrace event
PTRACE_EVENT_EXIT, which is a prerequisite for the exec event support.
- Patch 2/4 implements the exec event support.
- Patch 3/4 adds documentation for the new RSP "Stop Reply" message.
- Patch 4/4 extends the tests gdb.threads/non-ldr-exc-[1-4].exp to
test in non-stop mode as well as in all-stop mode.

There are a couple of significant aspects to this patch.  First, it
uses the ptrace extension PTRACE_EVENT_EXIT to detect thread exit,
in particular the exit of a thread group leader when a non-leader
calls exec.  Use of this event was necessary due to a race condition
in the two-thread case.  It is only used internally; exit events
detected this way are not exposed to the user, and exit processing
was changed as little as possible.

Second, it sends a signal to each lwp after an exec event in order to
identify and clean up the lwp entry for the exec'ing thread.  This
happens in the normal course of things for all-stop mode, but in non-stop
mode gdbserver uses SIGSTOP to stop, then resume all of the non-leader
threads to accomplish this.

More detailed explanations of these issues is included in the patch 2/4
email.

My intent is to follow up with implementations of remote fork/vfork events and
associated catchpoints.

--Don

 gdb/common/linux-ptrace.c                   |  45 ++++-
 gdb/doc/gdb.texinfo                         |   6 +
 gdb/gdbserver/linux-low.c                   | 274 +++++++++++++++++++++++++---
 gdb/gdbserver/linux-low.h                   |   5 +
 gdb/gdbserver/remote-utils.c                |  28 ++-
 gdb/remote.c                                |  27 ++-
 gdb/testsuite/gdb.threads/non-ldr-exc-1.exp |  15 +-
 gdb/testsuite/gdb.threads/non-ldr-exc-2.exp |  15 +-
 gdb/testsuite/gdb.threads/non-ldr-exc-3.exp |  15 +-
 gdb/testsuite/gdb.threads/non-ldr-exc-4.exp |  15 +-
 10 files changed, 395 insertions(+), 50 deletions(-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]