Re: [PATCHv2 4/5] gdbserver: cleanup in handle_v_run

[Andrew Burgess <aburgess@redhat.com>]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Andrew> After the previous commit there is now a redundant string copy in
> Andrew> handle_v_run, this commit cleans that up.
>
> Andrew> +	  /* Buffer to decode the argument into.  */
> Andrew>  	  char *arg = (char *) xmalloc (len + 1);
> ... 
> Andrew>  	  hex2bin (p, (gdb_byte *) arg, len);
> Andrew>  	  arg[len] = '\0';
>  
> Not really your problem, but since you're changing it anyway, using the
> byte_vector form of hex2bin would remove some manual memory management
> here.

I see two problems with that plan.  First, we currently run hex2bin on a
slice of a larger string buffer, the slice is not null-terminated.  The
current hex2bin that returns a gdb::byte_vector expects a
null-terminated string (it uses strlen internally).  We can easily solve
this by adding an overload of hex2bin that takes a gdb::string_view,
except...

... for the second problem, which is the result of calling hex2bin is
passed off to either new_program_name or the new_argv vector.  There's
no way to "release" the memory from a gdb::byte_vector, so we'd end up
copying the contents into a malloc'd buffer anyway, like:

  gdb::byte_vector vec = hex2bin (gdb::string_view (p, (next_p - p)));
  const char *arg = xstrdup ((const char *) vec.data ());

Which I'm not sure is really any better than we have right now?

Did you have something else in mind?  Let me know and I'm happy to have
a look at an alternative approach.

Thanks,
Andrew