This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Variable objects laziness
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