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

["Maciej W. Rozycki" <macro at mips dot 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