Re: [PATCH 2/3] gdbserver/linux: Access memory even if threads are running

[Pedro Alves <pedro@palves.net>]

On 2022-03-31 12:39, Pedro Alves wrote:
> On 2022-03-30 14:22, Lancelot SIX wrote:
>>> +/* Helper for read_memory/write_memory using /proc/PID/mem.  Because
>>> +   we can use a single read/write call, this can be much more
>>> +   efficient than banging away at PTRACE_PEEKTEXT.  Also, unlike
>>> +   PTRACE_PEEKTEXT/PTRACE_POKETEXT, this works with running threads.
>>> +   One an only one of READBUF and WRITEBUF is non-null.  If READBUF is
>>> +   not null, then we're reading, otherwise we're writing.  */
>>
>> Hi,
>>
>> Seems to me that this property can be asserted.  WDYT?
>>
>> Something like
>>
>>     gdb_assert ((readbuf == nullptr) != (writebuf == nullptr));
>>
>> should do.
>>
> 
> Doesn't hurt.  I've added that locally.  Thanks.

Funny enough, it does hurt...  Running the testsuite with that change
shows the assertion triggering.  This is because GDB may ask to write LEN==0
bytes, and we have this

 int
 target_write_memory (CORE_ADDR memaddr, const unsigned char *myaddr,
 		     ssize_t len)
 {
   /* Make a copy of the data because check_mem_write may need to
      update it.  */
   gdb::byte_vector buffer (myaddr, myaddr + len);
   check_mem_write (memaddr, buffer.data (), myaddr, len);
   return the_target->write_memory (memaddr, buffer.data (), len);
 }

... and buffer.data() may return NULL if the vector is empty.  I've added
a new patch to the series to add an early return if len==0.  I'll send
a v2 series in a bit.