From: Josh Stone <jistone@redhat.com>
To: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
Cc: philippe.waroquiers@skynet.be, sergiodj@redhat.com, eliz@gnu.org,
xdje42@gmail.com
Subject: Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver
Date: Fri, 11 Dec 2015 21:19:00 -0000 [thread overview]
Message-ID: <566B3DD8.9050206@redhat.com> (raw)
In-Reply-To: <566248F2.5020908@redhat.com>
On 12/04/2015 06:16 PM, Josh Stone wrote:
> On 12/04/2015 05:18 AM, Pedro Alves wrote:
>> Quick question: What is supposed to happen to the QCatchSyscalls
>> when the process execs? I'm thinking of 64-bit inferior execing
>> 32-bit inferior, etc. The syscall numbers aren't necessarily shared
>> between the different architectures. This implementation deletes discards
>> the previous QCatchSyscalls on exec, and I think that's what makes sense,
>> but, I think that this should be explicit in the packet's description.
>
> Yes, I think it should be cleared to avoid any assumption about the
> architecture. I'll add a note in the description codifying this.
After exploration, I'm having second thoughts about this point. Yes,
the current implementation clears it, but only when PTRACE_O_TRACEEXEC
is enabled to actually get that event. That's only if the client sent
"qSupports:exec-events+". Otherwise, the server doesn't even know an
exec happened, so it can't really promise to reset the syscall table.
Since the server doesn't promise to always catch execs, I think we
should actually go the other way to stay consistent. Let the syscall
list be carried over, and document that clients should probably send a
new list after execs in case the architecture changed. Some clients may
just choose to live with the assumption that the arch is consistent in
their environment.
Thoughts?
>> I'm not sure gdb clears the inferior's "syscalls to the caught" VEC
>> on exec events, but it probably does (if it doesn't, I think it should.)
>
> I'll see if I can find out.
AFAICT the only time anything is removed from syscall_catchpoint's VEC
syscalls_to_be_caught is in breakpoint_ops->remove_location and ->dtor,
respectively remove_catch_syscall and dtor_catch_syscall. And since
this list isn't stored in the lwp structure itself, the exec doesn't
really affect anything. Right?
next prev parent reply other threads:[~2015-12-11 21:19 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 11:02 [PATCH] " 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 ` [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP Pedro Alves
2015-11-30 18:50 ` 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 [this message]
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=566B3DD8.9050206@redhat.com \
--to=jistone@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@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).