[gdbserver] Don't assume vCont;r ADDR1,ADDR2 comes with a ptid attached.
authorPedro Alves <palves@redhat.com>
Fri, 24 May 2013 11:28:06 +0000 (11:28 +0000)
committerPedro Alves <palves@redhat.com>
Fri, 24 May 2013 11:28:06 +0000 (11:28 +0000)
commit6740dc9c3e1fbc0f2ae2cb54feee654023db157d
treeefed607693ec51e238eb675f4eb89fd0814ce0fd
parentdb1ac43683fc23c0e1a1b2bd5715114dde0380a0
[gdbserver] Don't assume vCont;r ADDR1,ADDR2 comes with a ptid attached.

This bit:

+   p1 = strchr (p, ':');
+   decode_address (&resume_info[i].step_range_end, p, p1 - p);

should not expect the ':' to be there.  An action without a ptid is
valid:

 "If an action is specified with no thread-id, then it is applied to any
 threads that don't have a specific action specified"

This is handled further below:

      if (p[0] == 0)
{
  resume_info[i].thread = minus_one_ptid;
  default_action = resume_info[i];

  /* Note: we don't increment i here, we'll overwrite this entry
     the next time through.  */
}
      else if (p[0] == ':')

A stub that doesn't support and report to gdb thread ids at all (like
metal metal targets) only will always only see a single default action
with no ptid.

Use unpack_varlen_hex instead of decode_address.  The former doesn't
need to be told where the hex number ends, and it actually returns
that info instead, which we can use for validation.

Tested on x86_64 Fedora 17.

gdb/gdbserver/
2013-05-24  Pedro Alves  <palves@redhat.com>

* server.c (handle_v_cont) <vCont;r>: Use unpack_varlen_hex
instead of strchr/decode_address.  Error if the range isn't split
with a ','.  Don't assume there's be a ':' in the action.
gdb/gdbserver/ChangeLog
gdb/gdbserver/server.c