Debugger doesn't correctly handle anonymous unions within structs/classes

[anevilyak]

While attempting to debug error messages relating to invalid DW_AT_specification attributes with programs generated by our newer gcc4, I'm running into issues digging into what's actually going on because Debugger isn't properly able to represent the AttributeValue class. The anonymous union is simply shown as a blank value node that expands to another instance of the AttributeValue class with the same blank value node ad infinitum. At the moment I'm not really clear as to what's going on though, since the same union declared outside of a class works fine. Attached a simplified test program which reproduces the issue ; the compiler used to generate the DWARF output in question doesn't appear to matter, it's reproducible with both 2 and 4.

[anevilyak]

Also, may or may not be related, but in the case where the union is declared standalone, while it's more or less represented properly, the const void* data member of the block member doesn't appear at all in the value list, though the length member does.

[anevilyak]

Seems to be a problem in the type/value handler roster somewhere ; the unnamed member is enumerated with the correct size according to tracing so it doesn't appear DWARF parsing-related, but the type/value handlers are assigning it as the same class as the parent rather than as its appropriate union type. That having been said, this should also probably be special-cased and the node hidden as we do for the case of a pointer pointing to a single compound node, such that its members appear directly as class members, unless you have any objections to that.

[bonefish]

The union members aren't members of the enclosing class and I would find it rather confusing, if they were displayed that way. I'd rather have a subnode for the union (maybe named "<unnamed union>" or something like that), which, at least in theory, should already happen. No clue why it doesn't work correctly yet.

[anevilyak]

Replying to bonefish:

The union members aren't members of the enclosing class and I would find it rather confusing, if they were displayed that way.

The main reason I thought it might be nice is because when one has them, in code one addresses them as if they're simply members of the struct anyways, but I'm fine with either way.

I'd rather have a subnode for the union (maybe named "<unnamed union>" or something like that), which, at least in theory, should already happen. No clue why it doesn't work correctly yet.

A node does get created, with no name whatsoever, though the latter part should be easily fixable. After digging a bit further though, it smells more like a problem in DwarfTypeFactory. The DIE output for both the union and struct looks sane, but when we go to create the children of the struct's compound value node, the first data member has a type corresponding to that of its parent struct rather than that of the union. Could possibly be related to the changes I made a while ago concerning that infinite recursion bug while creating types, will see what I can find out.

[anevilyak]

Problem found:

In DwarfTypeFactory::CreateType(), we call GetFullyQualifiedDIEName() on the type entry. The latter finds the entry to have no name, since it's an anonymous union, finds neither an abstract origin nor a specification, and then starts trying to build the name from the namespace. This ends up with the name of the parent struct, then finds that the entry has no name, and finishes there. Consequently we just get back the name of the parent struct as the fully qualified DIE name and thus find it in the type cache and assign that to it, leading to the observed issue. I'm not really sure as to the best way to fix that without breaking anything else though. Hypothetically, assigning it the name "<unnamed union>" while parsing the DIE might work, since then we'd get a name, fail to find an actual type by it, and then fall back to looking up the type by ID. Thoughts?

[anevilyak]

Scratch that, actual problem found. Fixed in hrev43436.