From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2728 invoked by alias); 12 Jan 2002 01:04:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2692 invoked from network); 12 Jan 2002 01:04:04 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 12 Jan 2002 01:04:04 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 922543D0D; Fri, 11 Jan 2002 20:03:53 -0500 (EST) Message-ID: <3C3F8B79.9000100@cygnus.com> Date: Fri, 11 Jan 2002 17:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbtypes.[ch] rs6000-tdep.c--AltiVec regs types References: <15423.26637.972974.400390@localhost.cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00315.txt.bz2 Your post prompted me to dig. It is just that I kind of regret this exposure of a GCC internal naming convention (SI, QI, FI, HI, ...) to the innocent end user. Is the convention really set in stone or can we reform our ways? :-) The relevant thread is: http://sources.redhat.com/ml/gdb-patches/1999-q4/msg00316.html As an aside, it did take a few years but there are now both more explicit builtin fp types (see builtin_type_ieee ...); and implemented the virtual to raw register mapping the thread talks about for MMX. The i386 MMX registers can finally be implemented as (looks in sandpit, for wip code): static void i386_register_read (struct gdbarch *gdbarch, int regnum, char *buf) { if (is_mmx_regnum (regnum)) { char *mmx_buf = alloca (MAX_REGISTER_RAW_SIZE); int fpnum = mmnum_to_fpnum (regnum); regcache_read (fpnum, mmx_buf); /* Extract (always little endian). */ memcpy (buf, mmx_buf, REGISTER_RAW_SIZE (regnum)); } else regcache_read (regnum, buf); } (probably time to submit that patch). Anyway, regarding your patch, perhaps move the construct to gdbtypes.[hc] to encourage its re-use by other Altivecish targets. Andrew PS: Check the man page for [x]calloc() GDB could benefit from its use. Two questions. > +static struct type * > +build_builtin_type_powerpc_altivec (void) > +{ > + /* Construct a type for the AltiVec registers. The type we're building > + is this: */ > +#if 0 > + union __gdb_builtin_type_powerpc_altivec > + { > + struct __builtin_v16qi v16qi; > + struct __builtin_v8hi v8hi; > + struct __builtin_v4si v4si; > + struct __builtin_v4sf v4sf; > + uint128_t uint128; > + }; > +#endif > + > + struct type *t; > + struct field *f; > + > + f = (struct field *) xmalloc (sizeof (*f) * 5); > + memset (f, 0, sizeof (*f) * 5); > + > + FIELD_TYPE (f[0]) = builtin_type_int128; > + FIELD_NAME (f[0]) = "uint128"; > + > + FIELD_TYPE (f[1]) = builtin_type_v4sf; > + FIELD_NAME (f[1]) = "v4sf"; > + > + FIELD_TYPE (f[2]) = builtin_type_v4si; > + FIELD_NAME (f[2]) = "v4si"; > + > + FIELD_TYPE (f[3]) = builtin_type_v8hi; > + FIELD_NAME (f[3]) = "v8hi"; > + > + FIELD_TYPE (f[4]) = builtin_type_v16qi; > + FIELD_NAME (f[4]) = "v16qi"; > + > + /* Build a union type with those fields. */ > + t = init_type (TYPE_CODE_UNION, 16, 0, 0, 0); > + TYPE_NFIELDS (t) = 5; > + TYPE_FIELDS (t) = f; > + TYPE_TAG_NAME (t) = "__gdb_builtin_type_powerpc_altivec"; > + > + return t; > +} > + >