[bug] fetch_register_using_p() is not endian-ness safe

[Theodore A. Roth]

Hi,

Just got bit by this one.

The recent changes to remote.c to implement 'p' packets using
fetch_register_using_p() is broken.

It is padding out the hex-ified regnum with zeros, but the resulting
endian-ness is tied to the gdb host. For example, on my x86 linux box,
fetching the PC, gdb sends this packet:

	"$p22000000#f4"

while on Paul's powerpc system, he sees this packet:

	"$p00000022#f4"

This poses a problem for the remote target when the stub needs to parse
this packet since the byte ordering is not well defined.

The problem code is this line in remote.c:

  bin2hex((char *) &regnum, &buf[1], sizeof(regnum));

What's the proper way to handle this? Seems to me that bin2hex() is not
even needed in this case, wouldn't a simple snprintf() be a bit more
sane? Something like this maybe:

  snprintf (buf+1, rs->remote_packet_size-1, "%X", regnum);

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: troth@jabber.org