MI: fix base members in references
Vladimir Prus
ghost@cs.msu.su
Thu Dec 7 06:53:00 GMT 2006
Vladimir Prus wrote:
> On Thursday 07 December 2006 07:57, Nick Roberts wrote:
>> Nick Roberts writes:
>> > More generally variable objects still don't seem to work (even with
>> > Vladimir's yet to be committed patch) for references to pointers.
>> >
>> > Assuming that the test program below makes sense, a variable object
>> > for n1 has a value which includes the address and reports the value
>> > has changed (as it used to do for pure references)
>>
>> Sorry thats actually rubbish (I was using an old GDB), but for
>>
>> struct S { int i; int j; };
>>
>> S *s;
>> S *&s1 = s;
>>
>> -var-create - * s
>> ^done,name="var1",numchild="1",type="S *"
>> (gdb)
>> -var-create - * s1
>> ^done,name="var2",numchild="0",type="S *&"
>>
>> so the pointer is dereferenced by GDB but the reference to the pointer is
>> not. I think that they should work in the same way but I'm not sure.
>
> Guess what happens? The code path that computes the number of children --
> namely c_number_of_children -- does not seem to handle references.
>
> So even while the underlying value is passed via coerce_ref, the reported
> number of children
> is always 0, so you can't get any children. Ick!
>
> On the other hand, that's no something that I've broke -- I did not even
> touch c_number_of_children or anything related. I guess we need to first
> commit the primary references patch and then fix c_number_of_children. Not
> that I find references to pointers very common thing, but better be
> correct.
To avoid potential confusion -- cplus_number_of_children does not handle
references. c_number_of_children is not expected to,
cplus_number_of_children might handle them, but does not.
- Volodya
More information about the Gdb-patches
mailing list