This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: powerpc remote target registers
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 02 Dec 2003 05:22:58 +0000
- Subject: Re: powerpc remote target registers
- References: <3FC7FF5D.7060906@eCosCentric.com> <3FCB8DDC.30603@gnu.org>
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