From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12679 invoked by alias); 15 Nov 2006 16:25:04 -0000 Received: (qmail 12656 invoked by uid 22791); 15 Nov 2006 16:25:04 -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; Wed, 15 Nov 2006 16:24:57 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GkNZG-0007lG-70 for gdb-patches@sourceware.org; Wed, 15 Nov 2006 11:24:54 -0500 Date: Wed, 15 Nov 2006 16:25:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: Variable objects laziness Message-ID: <20061115162454.GA29310@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <200611141643.25053.vladimir@codesourcery.com> <20061114204721.GA11963@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00127.txt.bz2 On Wed, Nov 15, 2006 at 12:04:08PM +0300, Vladimir Prus wrote: > > Neither before nor after this patch do I really understand what > > "type_changeable" means so I'll trust you've got it right :-) > > Do you want to me add a comment to that function? Since you seem to know what it's used for and why it relates to fetching things, yes please. > > Will we do eight reads from the target for this? > > > > struct x { > > unsigned char a:1, b:1, c:1, d:1, e:1, f:1, g:1, h:1; > > }; > > No. Look at value_primitive_field. For bitfeilds, it calls > unpack_field_as_long, passing value_contents (args1) to it. The > value_contents function will read entire structure from memory on the first > time. For the second bitfield, the already-read data will be used. Oh. So non-bitfield members will be read lazily, but bitfield members will cause a read of their immediate container. That's a little strange, but since I think it's exactly what we want to happen right now, let's leave it alone :-) > I think I can address this issue by making install_new_value always fetch > values of unions. > > Or I can do nothing, because in CLI, if your program is: > > struct S > { > union { > int i; > int j; > }; > }; > > int main() > { > S s; > ..... > > And you do: > > print s.i > print s.j > > it will generate two reads of memory too. Right - but only one read for "print s". If you think fetching the value of unions is reasonable, let's do that. > What do you mean? The second line is indented 6 spaces, so it can use tab > for indentation. Sorry, you're right! When you're ready, please repost. Might want to finish talking with Nick first. -- Daniel Jacobowitz CodeSourcery