Opened 8 years ago

Closed 8 years ago

#8190 closed bug (fixed)

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

Reported by: anevilyak Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by 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.

Attachments (1)

union_test.cpp (598 bytes ) - added by anevilyak 8 years ago.

Download all attachments as: .zip

Change History (8)

by anevilyak, 8 years ago

Attachment: union_test.cpp added

comment:1 by anevilyak, 8 years ago

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.

comment:2 by anevilyak, 8 years ago

Description: modified (diff)

comment:3 by anevilyak, 8 years ago

Owner: changed from bonefish to anevilyak
Status: newassigned

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.

comment:4 by bonefish, 8 years ago

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.

in reply to:  4 ; comment:5 by anevilyak, 8 years ago

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.

in reply to:  5 comment:6 by anevilyak, 8 years ago

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?

comment:7 by anevilyak, 8 years ago

Resolution: fixed
Status: assignedclosed

Scratch that, actual problem found. Fixed in hrev43436.

Note: See TracTickets for help on using tickets.