Re: [PATCH 25/31] Ignore failure to read PC when resuming

Pedro Alves
2023-11-13T14:13:23Z

On 2023-06-10 11:33, Andrew Burgess wrote:
> Pedro Alves <pedro@palves.net> writes:
>
>> If GDB sets a GDB_THREAD_OPTION_EXIT option on a thread, and the
>> thread exits, the server reports the corresponding thread exit event,
>> and forgets about the thread, i.e., removes the exited thread from its
>> thread list.
>>
>> On the GDB side, GDB set the GDB_THREAD_OPTION_EXIT option on a
>> thread, GDB delays deleting the thread from its thread list until it
>> sees the corresponding thread exit event, as that event needs special
>> handling in infrun.
>>
>> When a thread disappears from the target, but it still exists on GDB's
>> thread list, in all-stop RSP mode, it can happen that GDB ends up
>> trying to resume such an already-exited-thread that GDB doesn't yet
>> know is gone. When that happens, against GDBserver, typically the
>> ongoing execution command fails with this error:
>
> I'm slightly confused here. If GDB doesn't know the thread has exited
> doesn't that mean the server hasn't yet reported the exit, and so should
> be holding onto the thread?
>
> I wanted to investigate this a bit more to try and understand more about
> what's going on, but I couldn't find a test that was triggering the code
> added in this patch. Do you know if there's a test I can run to see
> this issue?

I think there was an existing testcase that would sometimes fail for this
problem, but looks like I didn't write that anywhere, and now I don't
remember... :-/ Sorry about this. I wasn't able to reproduce the
problem in a few test runs, so I will drop this patch from the series
for now until I find a better rationale, and we can discuss how to
fix it then.

Sorry again, and many thanks for the review and ideas.

Pedro Alves