RE: [cdt-dev] Problem with multiple anonymous fields in Variables view

["Mikhail Khodjaiants" <Mikhail.Khodjaiants@xxxxxxx>]

Rich,

I think it's a bug in gdb. We use var-evaluate-expression and
var-list-children to display the value and the structure of a
var-object, but both var-objects have the same name. 
Maybe somebody familiar with gdb internals can comment...

Thanks,
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Rich Wagner
Sent: 22 August 2007 18:03
To: CDT General developers list.
Subject: [cdt-dev] Problem with multiple anonymous fields in Variables
view

While using Eclipse 3.2 and CDT 3.1.2, we've come across a problem
involving multiple anonymous fields in structs or unions: they're not
being displayed correctly in the Variables view.  I tried to find an
existing Bugzilla entry for this (including fixed and open CDT 4.0
bugs), but found none: hence this email.  This test case illustrates the
problem:

    typedef union _my_union {
        int X;
        union {
            int Y;
            struct {
                unsigned A:16;
                unsigned B:16;
            };
            struct {
                unsigned C:8;
                unsigned D:24;
            };
        };
    } my_union_t;

    void test()
    {    
        my_union_t * ptr = (my_union_t *) calloc (1, sizeof
(my_union_t));
        ptr->X = 1;
    
        printf ("ptr->Y = %d\n", ptr->Y);
        printf ("ptr->A = %d\n", ptr->A);
        printf ("ptr->B = %d\n", ptr->B);
        printf ("ptr->C = %d\n", ptr->C);
        printf ("ptr->D = %d\n", ptr->D);
    
        printf ("Set Breakpoint Here\n");
    }

I set a breakpoint on the last "printf" in "test" and look at "ptr"s
data structure - fully expanded - in the Variables view.  The attached
snapshot illustrates the problem: fields "A" and "B" are not displayed:
instead, "C" and "D" are displayed twice.

The problem is NOT about anonymous fields in general: the problem only
involves two or more anonymous siblings.

To be specific: note that "X" and its anonymous sibling are displayed
correctly, i.e. the union correctly lists three children.  However, the
first of the two anonymous siblings of "Y" isn't displaying the correct
contents.

When I looked at the GDB/MI I/O for this, I found that the
"-var-list-children" commands used to populate the Variables view are
getting empty names for anonymous children (not too surprisingly).  In
particular, note the output of the last "-var-list-children" command
below, listing the children of the anonymous union:

    263-var-create - * ptr
    263^done,name="var1",numchild="2",type="my_union_t *"
          :
    266-var-list-children var1
    266^done,numchild="2",children=[
        child={name="var1.X",exp="X",numchild="0",type="int"},
        child={name="var1.",exp="",numchild="3",type="union {...}"}]
          :
    270^done,numchild="3",children=[
        child={name="var1..Y",exp="Y",numchild="0",type="int"},
        child={name="var1..",exp="",numchild="2",type="struct {...}"},
        child={name="var1..",exp="",numchild="2",type="struct {...}"}]

IMPORTANTLY, note that the second and third children have the same name.
THAT'S the problem: when the code then tries to find the children of
those second and third nodes, it uses the same name of "var1.." in both
cases.


So my questions are:

- Should I file a bug for this?  (If I can, I will: I'm not a
contributor.)

- I'm not an expert in GDB, nor the MI command syntax, but I'm left
  scratching my head as to how this COULD be fixed.  Is there some way
  (for instance) for Eclipse to construct "-var-create" expressions
which
  *unambiguously* refer to multiple anonymous siblings??  Or is this
  ultimately a problem with the GDB syntax??  Is there some way to refer
  to children by position number, instead of by name??

Thanks,
Rich


P.S. I understand that there's a workaround: name anonymous fields until
you no longer have more multiple anonymous siblings.  But -
unfortunately - that's not acceptable to one of our customers since that
would entail changes references to fields which "go through" the
newly-named subling: that customer has way too large of a code base to
like the idea of updating tons of references...


Rich Wagner, Senior Software Development Engineer Tilera Corporation
1900 West Park Drive, Suite 290 Westborough, MA 01581


-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.