Re: [RFA] W.I.P. AltiVec ppc registers support.

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Nov 28, 2001 at 09:15:35PM -0500, Elena Zannoni wrote:
> 
> AltiVec registers are 32 128-bit wide registers found on the G4
> powerpc processor family. This patch adds some initial support for
> such registers to gdb on a linux ppc platform.
> 
> The Altivec registers are not displayed in a normal 'info reg' command
> output. They are shown (like fp regs) if one says 'info all' instead.
> Furthermore I added a specific 'info power altivec' command to display
> just the Altivec registers. (I am not sure that the word 'power' is
> the best choice, maybe simply 'ppc' or 'powerpc' is better).  This way
> the command as just a specific powerpc info command, w/o it being a
> generic info command avaliable on every platform.

Use 'powerpc', please?  'power' is something quite different, and will
work as an abbreviation for powerpc anyway.

> If there is no kernel support for ptrace to handle the AltiVec
> registers, they will display as 0's.
> 
> The little drawback is that such registers will be displayed any time
> gdb's architecture is 'powerpc:common' or 'powerpc:7400'. The first
> case is the architecture gdb defaults to when run on a ppc machine,
> because the multiarch mechanism cannot determine the nature of the
> executable file. To be clearer, there is no way for gdb to know that
> the architecture is meant to be a ppc7400 based on executable
> information provided by BFD (unlike for Mips and Sh). So, gdb will
> always start and *stay* with a powerpc:common architecture selected,
> unless the user explicitly sets the architecture to be
> 'powerpc:7400'. This impossibility to auto detect the architecture is
> what prompted me to have Altivec defined anyway for the default
> arch. [Hopefully this deficiency will be rectified soon].

Hopefully.  I'd say this wasn't too big of a caveat for now, though,
and I and Andrew both seem to have ideas in this direction.

Other than that, I've got no real comments.  Looks pretty good.  There
are a number of very similar functions involved in the fetching/storing
that I'm a little unhappy with, but that seems to be about par for GDB.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer