From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-11945-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 7783 invoked by alias); 14 Jan 2002 16:12:36 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 7751 invoked from network); 14 Jan 2002 16:12:35 -0000
Received: from unknown (HELO cygnus.com) (205.180.230.5)
  by sources.redhat.com with SMTP; 14 Jan 2002 16:12:35 -0000
Received: from localhost.cygnus.com (cse.sfbay.redhat.com [205.180.230.236])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA15451;
	Mon, 14 Jan 2002 08:12:31 -0800 (PST)
Received: (from ezannoni@localhost)
	by localhost.cygnus.com (8.11.2/8.11.2) id g0EFPJN01577;
	Mon, 14 Jan 2002 10:25:19 -0500
From: Elena Zannoni <ezannoni@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <15426.63583.1880.290178@localhost.cygnus.com>
Date: Mon, 14 Jan 2002 08:12:00 -0000
To: Michael Snyder <msnyder@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] gdbtypes.[ch] rs6000-tdep.c--AltiVec regs types
In-Reply-To: <3C3F7858.694D1AD8@redhat.com>
References: <15423.26637.972974.400390@localhost.cygnus.com>
	<20020111182846.A15924@nevyn.them.org>
	<3C3F7858.694D1AD8@redhat.com>
X-Mailer: VM 7.00 under Emacs 20.7.1
X-SW-Source: 2002-01/txt/msg00390.txt.bz2

Michael Snyder writes:
 > Daniel Jacobowitz wrote:
 > >=20
 > > On Fri, Jan 11, 2002 at 05:32:45PM -0500, Elena Zannoni wrote:
 > > >
 > > > This patch provides a builtin union type for the AltiVec registers,
 > > > so that the printing of such regs is a bit more enlightening, like:
 > > >
 > > >
 > > > (gdb) p $vr0
 > > > $2 =3D {uint128 =3D 0x00000064000000c80000012c00000190,
 > > >       v4sf =3D {f =3D {1.40129846e-43, 2.80259693e-43, 4.20389539e-4=
3, 5.60519386e-43}},
 > > >       v4si =3D {f =3D {100, 200, 300, 400}},
 > > >       v8hi =3D {f =3D {0, 100, 0, 200, 0, 300, 0, 400}},
 > > >       v16qi =3D {f =3D "\0\0\0d\0\0\0=C8\0\0\001,\0\0\001\220"}}
 > > > (gdb) p $vr0.v4si
 > > > $3 =3D {f =3D {100, 200, 300, 400}}
 > > > (gdb) p $vr0.v4si.f[2]
 > > > $4 =3D 300
 > > > (gdb) p $vr0.v4si.f[2]=3D444
 > > > $5 =3D 444
 > >=20
 > > Why is the .f necessary?  Why not make $vr0.v4si an array rather than
 > > struct type?
 >=20
 > I know this is historical (it's been done the same way for other
 > targets),=20
 > and I'm guessing it's because a struct type can be passed by value,
 > while
 > an array type is always passed by reference.  You want a type that can
 > be passed to a function.
 >=20
 > I should know this (I've dealt with it before), but my=20
 > memory cache is shrinking with age and misuse.  ;-(


Yes, I found an old ChangeLog entry about this, saying the following:

"The compiler needs to use a struct because arrays aren't assignable,
and the compiler and the debugger should agree."

Elena