From: "Maciej W. Rozycki" <macro@mips.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: <gdb-patches@sourceware.org>, Pedro Alves <palves@redhat.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>, <tom@tromey.com>,
<simon.marchi@ericsson.com>
Subject: Re: GDB 8.1 release -- 2018-01-08 update
Date: Mon, 08 Jan 2018 09:55:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1801080920090.20647@tp.orcam.me.uk> (raw)
In-Reply-To: <20180108074937.fq44jr4qkdphgeew@adacore.com>
Hi Joel,
> * [Maciej] remote/22597
> Empty `qsThreadInfo' reply handling regression causing inability to execute
>
> I'm trying to understand whether this is specific to mips or more
> general. And whether this only affects GDB when debugging with older
> stubs or whether it affects us more generally.
>
> Depending on the answer, the issue might not be so severe as
> to hold the release.
>
> Maciej - can you tell where we are on this issue, and whether
> you think it really is blocking for 8.1?
GDB uses the special thread ID 0, standing for `any', which older
`gdbserver' versions do not recognise. It does not verify beforehand
whether `gdbserver' supports this request and does not handle an error
reply gracefully. Consequently an error reply to a `Hg0' packet issued
causes GDB to lose track of what is going on, making it impossible to
continue with the debug session. This happens with all sessions in the
initial connection handshake, making the combination of new GDB and old
`gdbserver' unusable.
Additionally a `Hg' packet with a legitimate thread ID (the only one at
this point) is issued, which is handled correctly and returns a successful
reply, immediately before the offending `Hg0' packet with no actions in
between. Which means the `Hg0' packet is not really needed as it wouldn't
do anything anyway if `gdbserver' supported it.
Previously no `Hg' packets were issued at this point in the initial
connection handshake; GDB was satisfied with the single thread ID returned
by `ThreadInfo' packet queries initially issued and didn't try at this
point to switch to the same thread either named explicitly or with the
special `any' thread ID, and debugging worked just fine.
I can see in the remote log however that an error reply returned in
response to `Hg0' issued earlier on is handled gracefully as is for `Hc-1'
issued elsewhere, so this is specific to the point and sequence shown in
the bug report, and likely the issuing place that is not prepared. I can
share the full good and bad log I have if that might help.
I have no low-level understanding as to how the offending commit actually
caused this change in behaviour, so I cannot comment on it. I think we
should avoid introducing functional regressions and continue supporting
older stubs, which people may (have to) use for one reason or another.
Therefore I think it would be preferable if we fixed the regression before
8.1.
Does it answer your question?
Maciej
next prev parent reply other threads:[~2018-01-08 9:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 7:49 Joel Brobecker
2018-01-08 9:55 ` Maciej W. Rozycki [this message]
2018-01-08 16:35 ` Pedro Alves
2018-01-08 17:00 ` Maciej W. Rozycki
2018-01-09 1:28 ` [PATCH] Fix backwards compatibility with old GDBservers (PR remote/22597) (Re: GDB 8.1 release -- 2018-01-08 update) Pedro Alves
2018-01-10 11:18 ` Maciej W. Rozycki
2018-01-11 0:36 ` Pedro Alves
2018-01-08 15:50 ` GDB 8.1 release -- 2018-01-08 update Simon Marchi
2018-01-08 15:53 ` Tom Tromey
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=alpine.DEB.2.00.1801080920090.20647@tp.orcam.me.uk \
--to=macro@mips.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@linux-mips.org \
--cc=palves@redhat.com \
--cc=simon.marchi@ericsson.com \
--cc=tom@tromey.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).