MI and anonymous unions

MI and anonymous unions

[Vladimir Prus]

I've noticed that MI does not work nice with anonymous unions. Consider this 
structure:

    struct S
    {
         union {
                int i;
                int j;
          };
    };

Traversing it with MI eventually gives:

  -var-list-children V.public
   ^done,numchild="1",children=[child={name="V.public.",exp="",numchild="1",
                 type="union {...}"}]
    (gdb)
    -var-list-children V.public.
    ^done,numchild="1",children=[
         child={name="V.public..public",exp="public",numchild="2"}]
     (gdb)
     -var-list-children V.public..public
     .....

Although this kinda works, I'm pretty sure UI won't be happy about empty 
expression for a variable object, and if you have two anonymous unions, you 
can't even address them.

How about using some unique identifier for variable objects corresponding for 
anonymous unions? Say "@N"?

- Volodya

Re: MI and anonymous unions

[Daniel Jacobowitz]

On Wed, Nov 15, 2006 at 12:38:16PM +0300, Vladimir Prus wrote:
> Traversing it with MI eventually gives:
> 
>   -var-list-children V.public
>    ^done,numchild="1",children=[child={name="V.public.",exp="",numchild="1",
>                  type="union {...}"}]
>     (gdb)
>     -var-list-children V.public.
>     ^done,numchild="1",children=[
>          child={name="V.public..public",exp="public",numchild="2"}]
>      (gdb)
>      -var-list-children V.public..public
>      .....
> 
> Although this kinda works, I'm pretty sure UI won't be happy about empty 
> expression for a variable object, and if you have two anonymous unions, you 
> can't even address them.

I'm not sure what to do for the empty expression.  There's nothing we
can put there which would act like a named union, since you need one
less period - hmm, we were just discussing an MI command to recreate
expressions the other day...

How do people use the exp="" result?  Should it be "<anonymous>"?

> How about using some unique identifier for variable objects corresponding for 
> anonymous unions? Say "@N"?

That sounds reasonable.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI and anonymous unions

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Wed, Nov 15, 2006 at 12:38:16PM +0300, Vladimir Prus wrote:
>> Traversing it with MI eventually gives:
>> 
>>   -var-list-children V.public
>>   
^done,numchild="1",children=[child={name="V.public.",exp="",numchild="1",
>>                  type="union {...}"}]
>>     (gdb)
>>     -var-list-children V.public.
>>     ^done,numchild="1",children=[
>>          child={name="V.public..public",exp="public",numchild="2"}]
>>      (gdb)
>>      -var-list-children V.public..public
>>      .....
>> 
>> Although this kinda works, I'm pretty sure UI won't be happy about empty
>> expression for a variable object, and if you have two anonymous unions,
>> you can't even address them.
> 
> I'm not sure what to do for the empty expression.  There's nothing we
> can put there which would act like a named union, since you need one
> less period - hmm, we were just discussing an MI command to recreate
> expressions the other day...
> 
> How do people use the exp="" result?  Should it be "<anonymous>"?

KDevelop uses it to construct the full expression, which will obviously
break. I'm not sure about Eclipse, I think it does the same.

But given that there's no way to put anything there that can be used to
recreate expression, I don't see much difference. "<anonymous>" would work
better if this is to be shown in some UI, I think.

>> How about using some unique identifier for variable objects corresponding
>> for anonymous unions? Say "@N"?
> 
> That sounds reasonable.

Ok.

- Volodya

Re: MI and anonymous unions

[Jim Ingham]

Support for anonymous unions & structures is another of the "things we  
fixed but haven't submitted back"...  We do pretty much what Vladimir  
suggests, though I use #anon#N for the varobj name: the choice doesn't  
much matter.  We still return a blank expression (since that's really  
what the  There's one other tricky bit 'caused by the fact that you  
might have more than one anonymous union or structure inside a  
structure.  This wouldn't be a problem, but the varobj code tends to  
look up structure elements by name, which obviously won't work here.   
So you have to convert all the code that looks up structure elements  
to use the index rather than the name.

Another of the things we do in our varobj code for C++ is that we look  
up the dynamic type of objects (the same mechanism that "set print  
object on" uses, and the value & children we return are based on the  
dynamic type.  As soon as you do that, you really do need a "give me  
the expression that can recreate this varobj" for child varobj's.     
Otherwise the MI client needs to get all these dynamic casts right to  
get down to the proper child, which is a bit of a pain.

But it's a generally useful command.  We called it "var-info-path- 
expression" and given a varobj, it returns the expression that if  
evaluated would result in the same value.  Xcode uses this for "show  
in separate window" actions in the debugger variable view.  You can  
also use the to eliminate the "." for the anonymous structures or  
unions - though of course the MI client could do this too...

Jim


On Nov 15, 2006, at 6:58 AM, Vladimir Prus wrote:

>
> Daniel Jacobowitz wrote:
>
>> On Wed, Nov 15, 2006 at 12:38:16PM +0300, Vladimir Prus wrote:
>>> Traversing it with MI eventually gives:
>>>
>>>   -var-list-children V.public
>>>
> ^ 
> done 
> ,numchild="1",children=[child={name="V.public.",exp="",numchild="1",
>>>                  type="union {...}"}]
>>>     (gdb)
>>>     -var-list-children V.public.
>>>     ^done,numchild="1",children=[
>>>          child={name="V.public..public",exp="public",numchild="2"}]
>>>      (gdb)
>>>      -var-list-children V.public..public
>>>      .....
>>>
>>> Although this kinda works, I'm pretty sure UI won't be happy about  
>>> empty
>>> expression for a variable object, and if you have two anonymous  
>>> unions,
>>> you can't even address them.
>>
>> I'm not sure what to do for the empty expression.  There's nothing we
>> can put there which would act like a named union, since you need one
>> less period - hmm, we were just discussing an MI command to recreate
>> expressions the other day...
>>
>> How do people use the exp="" result?  Should it be "<anonymous>"?
>
> KDevelop uses it to construct the full expression, which will  
> obviously
> break. I'm not sure about Eclipse, I think it does the same.
>
> But given that there's no way to put anything there that can be used  
> to
> recreate expression, I don't see much difference. "<anonymous>"  
> would work
> better if this is to be shown in some UI, I think.
>
>>> How about using some unique identifier for variable objects  
>>> corresponding
>>> for anonymous unions? Say "@N"?
>>
>> That sounds reasonable.
>
> Ok.
>
> - Volodya
>

Re: MI and anonymous unions

[Vladimir Prus]

On Wednesday 15 November 2006 20:20, Jim Ingham wrote:
> Support for anonymous unions & structures is another of the "things we
> fixed but haven't submitted back"...  We do pretty much what Vladimir
> suggests, though I use #anon#N for the varobj name: the choice doesn't
> much matter.  We still return a blank expression (since that's really
> what the  There's one other tricky bit 'caused by the fact that you
> might have more than one anonymous union or structure inside a
> structure.  This wouldn't be a problem, but the varobj code tends to
> look up structure elements by name, which obviously won't work here.
> So you have to convert all the code that looks up structure elements
> to use the index rather than the name.

Ah, I see. So this is not as easy change as I though.

> Another of the things we do in our varobj code for C++ is that we look
> up the dynamic type of objects (the same mechanism that "set print
> object on" uses, and the value & children we return are based on the
> dynamic type.  As soon as you do that, you really do need a "give me
> the expression that can recreate this varobj" for child varobj's.
> Otherwise the MI client needs to get all these dynamic casts right to
> get down to the proper child, which is a bit of a pain.

Good point.

> But it's a generally useful command.  We called it "var-info-path-
> expression" and given a varobj, it returns the expression that if
> evaluated would result in the same value.  Xcode uses this for "show
> in separate window" actions in the debugger variable view.  You can
> also use the to eliminate the "." for the anonymous structures or
> unions - though of course the MI client could do this too...

In fact, I've posted a patch that ports -var-info-path-expression to mainline 
some time ago and we talked briefly with Daniel some time ago.

I'll see if I can revive that patch.

Thanks,
Volodya

Re: MI and anonymous unions

[Jim Ingham]

On Nov 15, 2006, at 9:27 AM, Vladimir Prus wrote:

> On Wednesday 15 November 2006 20:20, Jim Ingham wrote:
>> Support for anonymous unions & structures is another of the "things  
>> we
>> fixed but haven't submitted back"...  We do pretty much what Vladimir
>> suggests, though I use #anon#N for the varobj name: the choice  
>> doesn't
>> much matter.  We still return a blank expression (since that's really
>> what the  There's one other tricky bit 'caused by the fact that you
>> might have more than one anonymous union or structure inside a
>> structure.  This wouldn't be a problem, but the varobj code tends to
>> look up structure elements by name, which obviously won't work here.
>> So you have to convert all the code that looks up structure elements
>> to use the index rather than the name.
>
> Ah, I see. So this is not as easy change as I though.

Yeah, I looked at the patch against our sources, and it is not hard,  
but it is annoyingly large.  Mostly just a matter of having to push  
stuff through interfaces where it wasn't intended to go.  I did it in  
two steps, because I didn't think about this complexity at first.  So  
I did the trivial bit with just adding the anon.  Then the major patch  
you can fetch from the Apple CVS with:

cvs -q diff -p -r 1.83 -r 1.84 varobj.c

>
>> Another of the things we do in our varobj code for C++ is that we  
>> look
>> up the dynamic type of objects (the same mechanism that "set print
>> object on" uses, and the value & children we return are based on the
>> dynamic type.  As soon as you do that, you really do need a "give me
>> the expression that can recreate this varobj" for child varobj's.
>> Otherwise the MI client needs to get all these dynamic casts right to
>> get down to the proper child, which is a bit of a pain.
>
> Good point.
>
>> But it's a generally useful command.  We called it "var-info-path-
>> expression" and given a varobj, it returns the expression that if
>> evaluated would result in the same value.  Xcode uses this for "show
>> in separate window" actions in the debugger variable view.  You can
>> also use the to eliminate the "." for the anonymous structures or
>> unions - though of course the MI client could do this too...
>
> In fact, I've posted a patch that ports -var-info-path-expression to  
> mainline
> some time ago and we talked briefly with Daniel some time ago.
>
> I'll see if I can revive that patch.
>

Thanks...

I just noticed that that code doesn't actually handle the anonymous  
structure case properly.  You have to check if the structure name is  
anonymous and not emit an extra ".".  Grrr...  I haven't fixed it yet.

Jim