Enhance DWARF parser to recognize (and skip) DW_TAG_member entries for static fields

[ma-neumann]

Dear dyninst team,

since DWARF3, static fields in C++ classes are represented by DW_TAG_variable entries and (newly added) DW_TAG_member entries. (Happened with GCC 6.2.1 here.) We found this note/issue on it: http://www.dwarfstd.org/ShowIssue.php?issue=161118.1

This seems not to be covered by dyninst yet when parsing structures: they are exposed as fields but with offset -1 in SymtabAPI. If I am not mistaken, fields exposed by SymtabAPI with offset == -1 can then be either constants or static fields.

As these fields are not part of the structures but global variables instead, we added a check to skip these newly added entries during DWARF parsing. What do you think about it?

We stumbled across this when parsing DWARF generated by GCC 6.2.1 from the following (the cyclic dependency was not handled by our code):

class A { ... static A a; ... };

[dyninst-jenkins]

Can one of the admins verify this patch?

[wrwilliams]

The naming here kind of obfuscates what you're actually testing, and for anything where errors are non-fatal, we prefer return values to outparams (especially when writing predicates like this). So I'd refactor isStaticStructMember a bit.

I think the overall logic we want is more precisely:

• Do we have a location? Add a field.
• Is this a named constant? Pass it over to parseConstant so that it will get handled uniformly if/when that gets implemented.
• Otherwise, skip (with a dwarf_printf indicating that we're doing so). It doesn't matter whether we're skipping this because we expect its location to be defined elsewhere or because we can't do anything with it; fields without offsets are not useful. Never add a field with offset -1.

Thoughts?

[ma-neumann]

Thanks for the heads up. The logic sounds perfect.

I have removed the new function again and tried to implement it 1:1, please see the second commit.

[wrwilliams]

ok to test