Re: [PATCH] gdbserver: try selecting a thread first to access memory

[Pedro Alves <pedro@palves.net>]

On 2023-07-18 14:36, Aktemur, Tankut Baris wrote:
> On Tuesday, July 18, 2023 3:09 PM, Pedro Alves wrote:

[ snip answers; thanks! ]

>> I'm wondering whether we should have something like:
>>
>>   if ((aspace_thread_specific (...) && set_desired_thread ())
>>       || set_desired_process ())
>>      res = read_inferior_memory (memaddr, myaddr, len);
>>   else
>>      res = 1;
> 
> I believe `aspace_thread_specific` would have to be a target-specific
> logic.  

Right.

> What you referred to in the comment [1] above, i.e.  "immediately
> exposed to the problem scenario and is forced to fix it", would be caught
> and the target would fix the problem by implementing `aspace_thread_specific`
> appropriately.  This makes sense to me.  

Exactly.

> An alternative would be that
> the target calls `set_desired_thread` itself, before accessing the memory,
> if it detects that the request is thread-specific.  I don't see any low-target
> using `set_desired_thread` ever in the gdbserver codebase, though.  So, it
> might be considered a breakage of abstraction.  Hence, your suggestion looks
> favorable.

Yeah, that'd be an abstraction violation.  Ideally, the gdbserver backends would
have no RSP awareness at all, and would even be reusable by GDB.
Many years ago, the abstraction didn't exist as it does today, and the backends
would even peek into the remote protocol message buffer.  That was all separated
out with the non-stop and multi-process work, IIRC, where gdbserver migrated to a
target_ops interface similar to GDB's.

Pedro Alves