From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3190 invoked by alias); 11 Nov 2002 00:57:17 -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 3183 invoked from network); 11 Nov 2002 00:57:16 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 11 Nov 2002 00:57:16 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18B4lb-0006ws-00 for ; Sun, 10 Nov 2002 20:57:35 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18B2uF-0000Ii-00 for ; Sun, 10 Nov 2002 19:58:23 -0500 Date: Sun, 10 Nov 2002 16:57:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA/types: Clean up use of field bitsize Message-ID: <20021111005823.GA19066@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020930010515.GA27762@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020930010515.GA27762@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00299.txt.bz2 On Sun, Sep 29, 2002 at 09:05:15PM -0400, Daniel Jacobowitz wrote: > Right now, we have this really disturbing comment: > > /* Size of this field, in bits, or zero if not packed. > For an unpacked field, the field's type's length > says how many bytes the field occupies. > A value of -1 or -2 indicates a static field; -1 means the location > is specified by the label loc.physname; -2 means that loc.physaddr > specifies the actual address. */ > > Think about this for a moment. While in practice a static member is never > going to be packed, and in at least C++ can not be a bit-field, that's not > logically obvious for other languages. I don't know Ada but I wouldn't be > surprised if there were some construct which violated this assumption. > > Worse, all sorts of places don't check for negative bitsize at all. It may > be that they're all safe - I didn't spend a lot of time working out problem > cases - but I have my doubts. > > So, since I needed to gain a new field here anyway, and since I have no > compunctions about shrinking this field a little (packed bitfields of size > greater than a couple of words are allowed in some languages IIRC (including > GNU C maybe? Although they are not allowed in ISO C99), but they're > definitely dodgy), and since signed bitfields are not portable, I cleaned up > the construct. It turned out to be painless except for making sure symbol > readers initialized it, which was a little tedious. > > This patch: > Moves 'artificial' out from 'loc' and makes it a bitfield > Creates a 'static_kind' bitfield > Makes 'bitsize' into a bitfield > > The goal is to allow more kinds of fields to be marked artificial - > particularly data members. After this patch I'll submit the followup to > mark DW_AT_artificial members as artificial types. > > OK? It's in. Now to do the followon for artificial members; this will let us hide _vptr members in type output if requested. And probably a set option to toggle the artificial behavior... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer