gdbserver: special case target_write_memory len==0

gdbserver: special case target_write_memory len==0

The next patch in this series adds a common helper routine for both
memory reads and writes, like this:

 static int
 proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf,
		  const gdb_byte *writebuf, int len)
 {
   gdb_assert ((readbuf == nullptr) != (writebuf == nullptr));
   ...
 }

 int
 linux_process_target::read_memory (CORE_ADDR memaddr,
                                    unsigned char *myaddr, int len)
 {
   return proc_xfer_memory (memaddr, myaddr, nullptr, len);
 }

 linux_process_target::write_memory (CORE_ADDR memaddr,
                                    const unsigned char *myaddr, int len)
 {
   return proc_xfer_memory (memaddr, nullptr, myaddr, len);
 }

Surprisingly, the assertion fails.  That happens because it can happen
that target_write_memory is called with LEN==0, due to this in
gdb/remote.c:

 /* Determine whether the remote target supports binary downloading.
    This is accomplished by sending a no-op memory write of zero length
    to the target at the specified address. (...) */

 void
 remote_target::check_binary_download (CORE_ADDR addr)
 {
 ...
       p = rs->buf.data ();
       *p++ = 'X';
       p += hexnumstr (p, (ULONGEST) addr);
       *p++ = ',';
       p += hexnumstr (p, (ULONGEST) 0);
       *p++ = ':';
       *p = '\0';

In this scenario, in gdbserver's target_write_memory, the "myaddr"
argument of the_target->write_memory is passed the data() of a local
gdb::byte_vector (which is a specialized std::vector).  It's valid for
std::vector::data() to return NULL when the vector is empty.

This commit adds an early return to target_write_memory to avoid
target backends having to care about this.  For good measure, do the
same on the read side, in read_inferior_memory.

Change-Id: Iac8f04fcf99014c624ef4036bd318ca1771ad491