This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patchv2 2/2] Workaround gdbserver<7.7 for setfs
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Gary Benson <gbenson at redhat dot com>
- Date: Sun, 3 Apr 2016 21:30:38 +0200
- Subject: Re: [patchv2 2/2] Workaround gdbserver<7.7 for setfs
- Authentication-results: sourceware.org; auth=none
- References: <20160319201842 dot GA16540 at host1 dot jankratochvil dot net> <56F13963 dot 9040204 at redhat dot com> <20160322131604 dot GA24312 at host1 dot jankratochvil dot net> <56F14F1E dot 5010606 at redhat dot com> <20160323211547 dot GA17400 at host1 dot jankratochvil dot net> <20160324220933 dot GA27445 at host1 dot jankratochvil dot net> <20160324223241 dot GB2548 at host1 dot jankratochvil dot net> <56FBDFE7 dot 90203 at redhat dot 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