From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Gary Benson <gbenson@redhat.com>
Subject: Re: [patchv2 2/2] Workaround gdbserver<7.7 for setfs
Date: Sun, 03 Apr 2016 19:30:00 -0000 [thread overview]
Message-ID: <20160403193038.GA28364@host1.jankratochvil.net> (raw)
In-Reply-To: <56FBDFE7.90203@redhat.com>
On Wed, 30 Mar 2016 16:17:11 +0200, Pedro Alves wrote:
> E.g., reading this I'm left wondering, did it always respond OK to
> unknown vFile packets, or to all unknown packets? I think it was
> actually the latter.
Yes.
> AFAICS from the commit you pointed at in v1, the "OK" was
> gdbserver mistaking any unknown packet for a vStopped packet,
> with vStopped being the notification ack for the "%Stop" RSP async
> notification. So it could also happen that gdb sends the setfs
> packet while gdbserver had a pending notification, and then
> gdbserver replies back a stop reply instead of "OK"...
OK, I did not realize this possible regression.
> We may need to guarantee an early enough setfs is attempted.
> Is that already the case?
For linux targets it is because they read:
/proc/29202/smaps
Although you are right that does not need to be the case for non-linux
targets. setfs packet seems to be implemented linux-independently.
> If I'm right and gdbserver mishandled _any_ unknown packet,
> then I wonder whether you fix this one, but will trip on another
> when you get past initial connection and actually do any serious
> debugging?
That would mean gdbserver < 7.7 did not work for "any serious debugging".
I have seen the regression only since "setfs" but I admit I did not do "any
serious debugging".
> If not, this may be sufficient. Otherwise, we may need to come up with
> a different workaround, maybe based on sending an early probe packet,
> like "MustReplyEmpty", to which well behaved stubs reply empty, just because
> that's not a known packet to them. If a stub replies something other than
> empty to that one, then maybe we should disable all other
> auto-probed packets... That may force-disable too much functionality though...
>
> So in sum:
The patch was fixing a common use case with RHEL<=7 targets. You have
provided out a counterexample that it may hypothetically regress in a racy
case of non-linux FSF gdbserver. Normally I would find this workaround
applicable only for RHEL GDBs but now that everything needs to be upstream
first the RHEL workaround needs to be implemented in FSF GDB first (where it
does not belong much IMNSHO). I will therefore try to implement the
"MustReplyEmpty" packet but I have no idea what effect will have your
mentioned "disable all other auto-probed packets".
Thanks,
Jan
next prev parent reply other threads:[~2016-04-03 19:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-19 20:18 [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read Jan Kratochvil
2016-03-22 9:15 ` Gary Benson
2016-03-22 12:24 ` Pedro Alves
2016-03-22 13:16 ` Jan Kratochvil
2016-03-22 13:56 ` Pedro Alves
2016-03-23 21:15 ` Jan Kratochvil
2016-03-24 16:59 ` Jan Kratochvil
2016-03-24 22:09 ` [patch] Workaround gdbserver<7.7 for setfs [Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read] Jan Kratochvil
2016-03-24 22:32 ` [patchv2 1/2] Workaround gdbserver<7.7 for setfs Jan Kratochvil
2016-03-24 22:32 ` [patchv2 2/2] " Jan Kratochvil
2016-03-30 14:17 ` Pedro Alves
2016-04-03 19:30 ` Jan Kratochvil [this message]
2016-04-04 21:14 ` [patchv3] " Jan Kratochvil
2016-04-05 16:29 ` Pedro Alves
2016-04-06 13:49 ` [patchv4] " Jan Kratochvil
2016-04-06 14:31 ` Pedro Alves
2016-04-06 15:19 ` [commit] " Jan Kratochvil
2016-04-06 19:09 ` [revert] " Jan Kratochvil
2016-04-26 21:29 ` [patchv5] " Jan Kratochvil
2016-04-27 9:59 ` Pedro Alves
2016-04-27 19:32 ` [commit+7.11] " Jan Kratochvil
2016-04-28 10:36 ` Gary Benson
2016-04-05 16:32 ` [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read Pedro Alves
2016-04-05 17:14 ` Jan Kratochvil
2016-04-05 16:58 ` Pedro Alves
2016-04-06 14:34 ` [commit] " Jan Kratochvil
2016-04-06 14:49 ` [commit fix] Revert check-in by a mistake in the previous commit [Re: [commit] Suggest newer gdbserver if it has no qXfer:exec-file:read] Jan Kratochvil
2016-04-06 15:04 ` [commit] Suggest newer gdbserver if it has no qXfer:exec-file:read Pedro Alves
2016-04-06 15:29 ` Jan Kratochvil
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=20160403193038.GA28364@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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).