Re: GDB 8.1 release -- 2018-01-08 update

Maciej W. Rozycki
2018-01-08T09:55:30Z

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