Re: [PATCH v3 5/8] gdbserver: Transmit target description ID in thread list and stop reply

Thiago Jung Bauermann via Gdb-patches
2023-02-02T21:44:22Z

Simon Marchi <simark@simark.ca> writes:

> On 2/1/23 07:07, Andrew Burgess via Gdb-patches wrote:
>> Additionally, I think it would be worth adding a new feature to the
>> qSupported packet, maybe 'per-thread-tdesc'. With this added, GDB would
>> be able to tell gdbserver that it supports this feature, and gdbserver
>> will be able to confirm that the feature is supported.
>>
>> I'm not 100% sure what we'd want to do if it turns out GDB doesn't
>> support the feature? Is it better to push on with GDB using the wrong
>> target description? Or would it be better if gdbserver exits with an
>> error suggesting the GDB needs updating? In some ways, _what_ we do
>> doesn't really matter to me, but I think having the feature will allow
>> us to pick a suitable error handling solution later if needed.
>>
>> I'd be happy if adding the feature was done as a separate patch in this
>> series, but I do think it should be part of this series.
>
> I forgot to comment on that part. Just to think out loud:

I tested the two cases you mentioned below.

> - If GDB supports the new feature but GDBserver doesn't, I guess that
> debugging works exactly like today? What happens today if a remote
> thread changes its SVE vector size, the registers that GDB shows will
> simply not reflect the reality, they might have bogus values, but
> debugging will otherwise work?

Yes, that's exactly what happens.

> - If GDB does not support the new feature but GDBserver does, I guess it
> is problematic, because GDBserver will assume that GDB will have
> adjusted its expectations about the length (and layout) of the g
> packet response, since it told GDB about the thread-specific tdesc.
> But since GDB doesn't know about thread-specific tdescs, it will try
> to interpret the g packet response with the register layout of the
> process-wide tdesc, possibly leading to the infamous "Remote 'g'
> packet reply is too long", if the received response is longer than
> expected.

This too.

> So, I agree that we need some feature flag for this.

Ok, I will add it for the next version of the patches.

--
Thiago