From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6801 invoked by alias); 8 Feb 2007 15:59:27 -0000 Received: (qmail 6793 invoked by uid 22791); 8 Feb 2007 15:59:26 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 08 Feb 2007 15:59:18 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HFBg3-00031B-2j; Thu, 08 Feb 2007 10:59:15 -0500 Date: Thu, 08 Feb 2007 15:59:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: Lazy bitfields Message-ID: <20070208155915.GA11057@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com References: <200701241123.43649.vladimir@codesourcery.com> <20070208152856.GG6861@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070208152856.GG6861@nevyn.them.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00079.txt.bz2 On Thu, Feb 08, 2007 at 10:28:56AM -0500, Daniel Jacobowitz wrote: > Second, I'm worried about the "offset" argument to > value_primitive_field. This was primarily for CHILL, due to a > strange choice when generating or reading debug info, and it's > possible that it's never non-zero any more, which would be nice. > But if it ever is non-zero, this will break it. It gets lumped > in with value_offset so when you call unpack_field_as_long in > value_fetch_lazy you can't pick it out again to apply it to the > parent. > > That's my only real concern with this patch; everything else > looks OK. I'm going to try to figure out if that argument is > ever non-zero or if we can eliminate it now. This is all very twisted. I bet we could eliminate the non-zero cases, but it would take some untangling - though the result would be simpler than what we have now. Here's a C++ test case: struct A { int x : 12; int y : 14; }; struct A a; struct pad { int useless; }; struct B : pad, A { int no; }; struct B b; If you print out b.y, value_primitive_field will be called with an offset of 4. arg1 will be a value of type B, but arg_type will be type A. I think it should have passed a value of type A, instead of trying to do two steps at once... but that's what it does now. The difference between value_type (arg1) and arg_type is something else I hadn't noticed before. That means you're saving a fieldno into arg_type but applying it to value_type (value_parent (val)), which has a similar problem. I think you can work around this in two ways. We could fix all the current jumping through hoops and eliminate the offset argument, or you could avoid using the parent's type or fieldno. You want value_bitsize bits, from the parents contents plus a bit offset of: ((value_offset (val) - value_offset (value_parent (val))) * 8 + value_bitpos (val)) The difference in the two offsets gives you back the 'offset' argument to value_primitive_field plus the byte offset of the field, the value_bitpos gives you the additional bit offset of the field. You'd need something like unpack_field_as_long, but one which replaced the type and fieldno arguments with field_type (for TYPE_UNSIGNED), bitpos, and bitsize. Did that make any sense at all? -- Daniel Jacobowitz CodeSourcery