[gdbserver] Don't assume vCont;r ADDR1,ADDR2 comes with a ptid attached.

[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.