This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[bug] fetch_register_using_p() is not endian-ness safe
- From: "Theodore A. Roth" <troth at openavr dot org>
- To: gdb at sources dot redhat dot com
- Cc: Paul Schlie <schlie at comcast dot net>
- Date: Tue, 19 Oct 2004 18:18:46 -0700 (PDT)
- Subject: [bug] fetch_register_using_p() is not endian-ness safe
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 *) ®num, &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