From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4850 invoked by alias); 31 Jan 2003 21:07:05 -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 4843 invoked from network); 31 Jan 2003 21:07:04 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 31 Jan 2003 21:07:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0VL74f13825 for ; Fri, 31 Jan 2003 16:07:04 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0VL73a09936 for ; Fri, 31 Jan 2003 16:07:03 -0500 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0VL73Q03990; Fri, 31 Jan 2003 16:07:03 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h0VL6v405351; Fri, 31 Jan 2003 14:06:57 -0700 Date: Fri, 31 Jan 2003 21:07:00 -0000 From: Kevin Buettner Message-Id: <1030131210657.ZM5350@localhost.localdomain> In-Reply-To: Jim Blandy "Re: [RFC] s390-tdep.c: Define address class functions for s390x" (Jan 31, 3:14pm) References: <1030127232625.ZM2026@localhost.localdomain> To: Jim Blandy , Kevin Buettner Subject: Re: [RFC] s390-tdep.c: Define address class functions for s390x Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00849.txt.bz2 On Jan 31, 3:14pm, Jim Blandy wrote: > This looks like a pretty straightforward definition of a new address > class. Is that right? Yes. > Since we only have one target using this facility at the moment, this > might be premature, but I wonder if it would be worthwhile to provide > standard, table-driven versions of *_address_class_type_flags_to_name, > and *_address_class_name_to_type_flags, so that a target could simply > say: > > static address_class_table s390_addr_classes[] = { > { "mode32", TYPE_FLAG_ADDRESS_CLASS_1 }, > { 0, 0 } > }; > ... > > use_address_class_table_in_gdbarch (gdbarch, s390_addr_classes); > > which would install the right methods. Or something like that. I think this idea is worth purusing once we have more than one target using the address class facilities. > Maybe even s390_address_class_type_flags could be handled by the same > table. I haven't thought it through. Yes, I agree. For s390, the byte size would be used. However, some other target my used the address class constant from the DWARF2 info or, perhaps, some combination of the two. That's why I think it'd be worth having a couple of other targets under our belts before adding this machinery. Kevin