powerpc remote target registers

[Jonathan Larmour <jifl at eCosCentric dot com>]

I've been having a problem where (via the MI interface, but that's 
irrelevant), GDB (6.0) would report e.g. "register vr8 not available", 
where "8" may be any number, changing each time the program is stepped or 
restarted. Register vr8 is an altivec register and my remote target does 
not support altivec.

What appears to be the problem is that the binaries built by 
powerpc-eabi-gcc are marked as being for architecture powerpc, machine 
"common" (by BFD in the ELF header). This tells GDB that it supports 
certain register sets, including altivec, i.e. vr* registers.

In fact the target doesn't support altivec, and the target sends a short 
packet compared to GDB's expectations, but that shouldn't matter as by 
rights GDB should just ignore registers the target doesn't supply, right? 
Certainly code appears to handle that case without a warning.

However, at the end of remote_fetch_registers(), it does a check for if 
any of the registers start with an "x" character. If it does, it is marked 
as invalid. However the buffer containing the register set is never 
initialised, and so contains random junk. The size of the altivec register 
set makes it more likely to find an "x" somewhere (although curiously it 
does happen more frequently than I'd expect). Which also explains it being 
a different register most times it's run.

Now, arguably this is a problem with GCC/GAS/GLD: there is a machine type 
specifically for mpc860 with the correct register definitions, instead of 
"common" with the correct register definitions. However GCC/GAS don't 
allow you to set that when compiling objects, and LD appears to ignore my 
request to set it explicitly when linking (using -A powerpc:mpc860). That 
shouldn't really be needed anyway, as it should be implied by a compile 
with -mcpu=860, but GCC doesn't pass anything to GAS/the linker to reflect 
that. Sigh.

However I would say that GDB is also mistaken for not initializing the 
packet buffer in remote_fetch_registers() to 0 first, so that registers 
that aren't supplied by the remote target don't have uninitialised data, 
which may include an "x" in them.

Another possibility is for the remote stub to send the much longer packets 
(nearly 2kb!) including the altivec registers, however this may cause 
backward compatibility problems with older GDBs which is very bad indeed 
for us. Instead GDB should be able to cope with stubs not returning full 
register sets despite expectations.

So, for that reason I suggest the attached patch. Sorry for the long 
e-mail for a one-liner :-).

Thanks,

Jifl

2003-11-29  Jonathan Larmour  <jifl@eCosCentric.com>

	* remote.c (remote_fetch_registers): Clear buf to avoid treating
	junk as register data.



--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

--- remote.c~	2003-06-30 16:51:49.000000000 +0100
+++ remote.c	2003-11-29 01:50:05.000000000 +0000
@@ -3440,10 +3440,11 @@ remote_fetch_registers (int regnum)
 	internal_error (__FILE__, __LINE__,
 			"Attempt to fetch a non G-packet register when this "
 			"remote.c does not support the p-packet.");
     }
 
+  memset (buf, 0, rs->remote_packet_size);
   sprintf (buf, "g");
   remote_send (buf, (rs->remote_packet_size));
 
   /* Save the size of the packet sent to us by the target.  Its used
      as a heuristic when determining the max size of packets that the