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

[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

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

[Daniel Jacobowitz]

On Tue, Oct 19, 2004 at 06:18:46PM -0700, Theodore A. Roth wrote:
> 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.

FYI, Jim Blandy noticed this a little earlier - and his patch for the
problem was just approved.

-- 
Daniel Jacobowitz