public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Josh Stone <jistone@redhat.com>, gdb-patches@sourceware.org
Cc: philippe.waroquiers@skynet.be, sergiodj@redhat.com, eliz@gnu.org,
	       xdje42@gmail.com
Subject: Re: [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP
Date: Thu, 26 Nov 2015 10:34:00 -0000	[thread overview]
Message-ID: <5656E02A.3090207@redhat.com> (raw)
In-Reply-To: <1448506425-24691-1-git-send-email-jistone@redhat.com>

On 11/26/2015 02:53 AM, Josh Stone wrote:
> The ptrace options should be set as soon as we know a thread is stopped,
> so no events can be missed.  There's an arch-setup early return that was
> effectively delaying this update before, and I found for instance that
> the first syscall event wouldn't be properly reported with TRACESYSGOOD.
> It's now more similar to the way that gdb/linux-nat.c handles it.

Hmm, I'm confused on how this resulted in the first syscall being misssed.
That early return happens when we're not executing the real inferior
yet -- the process is still running the "gdbserver --wrapper WRAPPER"
binary.

It's pedantically good, though not crucial, to set PTRACE_O_TRACEEXEC early for
that scenario, to get a real PTRACE_EVENT_EXEC event instead of a bare SIGTRAP
when the exec wrapper (or in the future, the shell, when we start inferiors
with the shell, like gdb does, for arg expansion and globbing) actually execs.

If the shell/wrapper forks, enabling fork events while still executing the
wrapper/shell breaks startup -- server.c:start_inferior.  The gdb
version (fork-child.c:startup_inferior) does handle TARGET_WAITKIND_FORKED,
but AFAICS forgets detaching/resuming the child...

We _must_ not catch syscall events while running the exec wrapper (or
the shell), otherwise server.c:start_inferior would get confused for seeing
unexpected syscall stops.  If the backend treats syscall catchpoints, it's OK,
since gdb won't insert catchpoints in the process until after vRun returns,
indicating the process is stopped at the entry point.  IIRC, gdb actually
does NOT handle catchpoint locations per-inferior today, but as long as
the backend side thinks of catchpoints per-inferior, we can fix the GDB side.

So all in all, I'm not sure this actually buys us anything other than need
to fix the wrapper/shell-forks case.

> 
> gdb/gdbserver/ChangeLog:
> 
> 2015-11-25  Josh Stone  <jistone@redhat.com>
> 
> 	* linux-low.c (linux_low_filter_event): Set ptrace options as soon as
> 	each thread is stopped, even before arch-specific setup.

Thanks,
Pedro Alves

  parent reply	other threads:[~2015-11-26 10:34 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 11:02 [PATCH] Implement 'catch syscall' for gdbserver Josh Stone
2015-10-30 13:26 ` Eli Zaretskii
2015-11-01 22:15 ` Doug Evans
2015-11-02 18:24   ` Josh Stone
2015-11-21 10:29     ` Philippe Waroquiers
2015-11-23  4:20       ` Doug Evans
2015-11-23  4:20 ` Doug Evans
2015-11-25  2:37   ` Josh Stone
2015-11-26  2:53 ` [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP Josh Stone
2015-11-26  2:54   ` [PATCH v2 2/2] Implement 'catch syscall' for gdbserver Josh Stone
2015-11-26 10:34   ` Pedro Alves [this message]
2015-11-30 18:50     ` [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP Josh Stone
2015-12-01 20:17       ` Josh Stone
2015-12-02 14:01         ` Pedro Alves
2015-12-04  2:26   ` [PATCH v3 1/2] gdbserver: set ptrace flags after creating inferiors Josh Stone
2015-12-04  2:27     ` [PATCH v3 2/2] Implement 'catch syscall' for gdbserver Josh Stone
2015-12-04  8:45       ` Eli Zaretskii
2015-12-05  2:14         ` Josh Stone
2015-12-05  8:02           ` Eli Zaretskii
2015-12-07 16:50             ` Josh Stone
2015-12-07 17:15               ` Eli Zaretskii
2015-12-04 13:18       ` Pedro Alves
2015-12-05  2:16         ` Josh Stone
2015-12-08 13:31           ` Pedro Alves
2015-12-08 19:02             ` Josh Stone
2015-12-08 13:37           ` Pedro Alves
2015-12-11 21:19           ` Josh Stone
2015-12-16 15:42             ` Pedro Alves
2016-01-09  3:09       ` [PATCH v4] " Josh Stone
2016-01-09  7:37         ` Eli Zaretskii
2016-01-11 17:44         ` Philippe Waroquiers
2016-01-12 12:05         ` Pedro Alves
2016-01-12 19:10           ` Josh Stone
2016-01-12 19:22             ` Pedro Alves
2016-01-12 20:01               ` Josh Stone
2016-03-29 14:27                 ` Yao Qi
2016-03-29 18:12                   ` Josh Stone
2016-03-29 23:49                     ` Josh Stone
2016-03-30 12:23                       ` Yao Qi
2016-03-31  1:10                         ` Josh Stone
2016-04-01 13:05                           ` Yao Qi
2016-04-01 16:38                             ` Josh Stone
2016-05-29 16:47         ` [doc] NEWS: QCatchSyscalls: simplify Jan Kratochvil
2016-05-29 17:29           ` Eli Zaretskii
2016-05-29 17:50             ` Jan Kratochvil
2016-05-29 18:19               ` Eli Zaretskii
2016-05-29 18:47                 ` [commit] " Jan Kratochvil
2015-12-04 12:16     ` [PATCH v3 1/2] gdbserver: set ptrace flags after creating inferiors Pedro Alves
2015-12-05  2:14       ` Josh Stone

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=5656E02A.3090207@redhat.com \
    --to=palves@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jistone@redhat.com \
    --cc=philippe.waroquiers@skynet.be \
    --cc=sergiodj@redhat.com \
    --cc=xdje42@gmail.com \
    /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).