From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6442 invoked by alias); 29 Jan 2003 23:14:30 -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 6435 invoked from network); 29 Jan 2003 23:14:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 29 Jan 2003 23:14:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18e3IW-00016i-00 for ; Wed, 29 Jan 2003 19:15:21 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18e1Q5-0006jA-00 for ; Wed, 29 Jan 2003 18:15:01 -0500 Date: Wed, 29 Jan 2003 23:14:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Move ``length'' from struct main_type to struct type Message-ID: <20030129231501.GA25517@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <1030129224829.ZM17897@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1030129224829.ZM17897@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00792.txt.bz2 On Wed, Jan 29, 2003 at 03:48:29PM -0700, Kevin Buettner wrote: > A while back, I introduced a change to dwarf2read.c in > read_tag_pointer_type() which was supposed to create a pointer type > variant of a (potentially) different length: > > if (TYPE_LENGTH (type) != byte_size || addr_class != DW_ADDR_none) > { > if (ADDRESS_CLASS_TYPE_FLAGS_P ()) > { > int type_flags; > > type_flags = ADDRESS_CLASS_TYPE_FLAGS (byte_size, addr_class); > gdb_assert ((type_flags & ~TYPE_FLAG_ADDRESS_CLASS_ALL) == 0); > type = make_type_with_address_space (type, type_flags); > } > ... > } > > TYPE_LENGTH (type) = byte_size; > > However, this code doesn't work correctly. As it stands now, the type > length is shared between all type variants (which differ only in > qualifiers). This means that as soon as the above TYPE_LENGTH > assignment is performed, all type variants end up getting the same > length. I should note that when I initially developed this code, I > did so on a branch which did not yet implement this sharing via struct > main_type. > > The patch below corrects this problem by moving the length field from > struct main_type to struct type. I am not entirely happy with this > approach, but the other approaches I've considered are even less > palatable. > > E.g, another approach that I considered would be to create a new type > which has a different main_type that varies only in the length field. > The problem with this is that the names end up being the same, and it > seems to me that there will be problems with searching and finding the > right type when the user specifies it by name. > > Certainly, if anyone can think of a better approach, I'd be happy to > hear about it. It won't actually create a problem if you give them different main types; the main type is purely internal to the type system, and is never searched directly. That said, while I'm not really happy with your approach either, I think it is more correct and less fragile in general. > Those of you reviewing this patch should carefully consider the > comment in replace_type(). I don't think the problem that I mention > there will actually arise since replace_type() is only called by symbol > readers which don't know how to (and indeed can't) create variants of > different sizes, so the situation described in the replace_type() comment > should never (at the moment anyway) arise. > > Comments? (I'll wait at least a week before checking this one in.) My only comment is that I'd rather you check in replace_type that there are no types on the variant ring with different space qualifiers, and internal_error if there are. How's that sound? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer