Re: powerpc remote target registers

[Jonathan Larmour <jifl at eCosCentric dot com>]

Andrew Cagney wrote:
> > 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. 
>
>
> I don't think this fixes the bug.  It will fill each nibble of the 
> altivec registers with (0 - '0') instead of zero (you should see this 
> with "maint print raw-registers").

Ah, it still came up with 0 until I did that so I thought that was it.

> Suggest instead changing the for loop filling in regs[] so that it 
> doesn't run off the end of the NUL terminated buf[] (I think this is the 
> real bug).

But then the registers aren't marked as cached at all, so they're now 
requested from the target each time you do "info all-registers", even 
though they come up with 0s. Should I pretend the registers not supplied 
by the target were 0, or should I mark them as unavailable (i.e. the same 
as what having an "x" does) so at least it's consistent?

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