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

[Pedro Alves <pedro@palves.net>]

On 2023-06-20 09:35, Tankut Baris Aktemur via Gdb-patches wrote:
> Since commit
> 
>   commit 7f8acedeebe295fc8cc1d11ed971cbfc1942618c
>   Author: Pedro Alves <pedro@palves.net>
>   Date:   Tue Apr 5 13:57:11 2022 +0100
> 
>     gdbserver: track current process as well as current thread
> 
> gdbserver switches to a process, rather than a thread, before
> processing a memory access request coming from the GDB side.  This
> switch sets current_thread to null.  Some memory accesses on certain
> targets, however, may require having a thread context.  Therefore, try
> switching to the selected thread first.  If this fails for a reason
> (e.g.  the thread has exited), switch to the process.

The reason I liked always selecting a process (with thread == null), is
that it made the corner case be the case that runs all the time.  I.e., any
target backend that incorrectly assumes there's always a thread selected,
is immediately exposed to the problem scenario and is forced to fix it.
Trying to select the thread first loses that.

If the access is for a thread-specific address space, and the thread exited,
what is supposed to happen?  Is the backend supposed to error out in that
scenario?  Or will it misbehave?

How do you tell what address space the access is targeting?  Are you encoding
that in the address, or do you have more changes to gdbserver, and maybe
RSP extensions?

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;