991110.1 | B | I | J. Merrill | C++ | Namespace support |
There are various alternatives for adding C++ namespace support to
dwarf2:
1) Use TAG_module
2) Add TAG_namespace
Another question to consider is how to deal with the fact that a namespace
can be extended after its initial definition has been closed. This means
that if we require DIEs of namespace-scope entities to be nested within the
namespace DIE, we cannot emit the debugging information as we go, we must
save it up and emit it at the end, once we've seen everything. gcc already
does that, but I don't know that we want to require it.
The alternative would be to add an AT_namespace to namespace-scope DIEs,
and emit them under the main CU DIE.
I propose that we use the preexisting DW_TAG_module to represent
namespaces, and nest entries for namespace members under that tag. To
handle namespace extension, we add a new attribute, DW_AT_extension,
which points to the DIE for the namespace being extended by the new
namepace DIE.
To handle using-declarations, I propose that we use the existing
DW_TAG_imported_declaration, and that we alter its description to not
require a DW_AT_name attribute if the imported copy uses the same name.
For using-directives, I suggest that we add a new
DW_TAG_imported_module, which would have a DW_AT_import referring to
the namespace being used.
Example: I forgot namespace aliases in my proposal; I
would think that we could use DW_TAG_imported_declaration for them,
too. Here's the example:
namespace {
int i;
};
namespace A {
namespace B {
int j;
}
}
using A::B::j;
namespace Foo = A::B;
using namespace Foo;
namespace A {
namespace B {
int k;
}
}
TAG_module
<no AT_name>
TAG_variable
AT_name "i"
...
0x1: TAG_module
AT_name "A"
0x2: TAG_module
AT_name "B"
0x3: TAG_variable
AT_name "j"
...
TAG_imported_declaration
AT_import 0x3
TAG_imported_declaration
AT_import 0x2
TAG_imported_module
AT_import 0x2
TAG_module
AT_extension 0x1
TAG_module
AT_extension 0x2
TAG_variable
AT_name "k"
...