> Date: Thu, 4 Mar 2010 18:06:11 -0800
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Thu, Mar 4, 2010 at 1:47 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> > On Thu, Mar 04, 2010 at 01:27:09PM -0800, H.J. Lu wrote:
> >> > No, it will fail to display SSE.  Core debugging should still be
> >> > possible, and the newly added registers will be visible too.  If
> >> > that's not the case, fix GDB to function with the SSE registers
> >> > missing.
> >>
> >> Your description only works for truly NEW registers, which
> >> AVX registers aren't.  AVX registers are actually the old SSE
> >> registers with different names.
> >
> > I'm trying to get you to think about compatibility in the
> > descriptions, instead of separately in the remote protocol.
> > There are always ways to solve it.  For instance, you could present
> > both the AVX registers and the hypothetical newer, larger registers as
> > separate things.  As long as the P packet is implemented, which it is,
> > GDB should work OK if modifying one register changes another.
> > I don't know if there's an example of this in the GDB sources, but I
> > have one in my tree; there's $sp, $sp_user, and $sp_system registers,
> > and $sp is the same as one of the other two depending on processor
> > mode.  But they're all visible.
> >
> > Another solution is to define new registers which correspond to the
> > added bits, and have a sufficiently recent GDB synthesize the combined
> > registers from the AVX registers and the new bits.  This, for
> > instance, is how the Power E500 registers are handled
> > (rs6000/power-spe.xml).
> >
> 
> OK, I will try SPE approach. It will take a while.

Wait, please.  I'll reply later when I have a bit more time, but I
don't think this will be a good idea.