[Dwarf-Discuss] name lookup w/ using directives

[Kendrick Wong]

I'm not trying to beat a dead horse. :-) Okay, maybe a little, taking it a 
step further, what about cross compilation unit inlining?  i.e. something 
in Fortran compilation unit is inlined into C++ compilation unit, then the 
language for the compilation unit becomes mixed, what is going to happen 
then?  What is the correct way to interpret the DW_TAG_imported_module 
then?

Is it the intention to have DW_TAG_imported_module carry DW_AT_language, 
so that consumer can decide which semantic to use?

Thanks,
Regards,

Kendrick Wong 
z/OS C/C++ Compiler 
Common Debug Architecture 
C2/YGK/8200/MKM 
kendrick at ca.ibm.com 
Office:905-413-2865 Fax:905-413-4839 Tie:313-2865 




From:
John DelSignore <jdelsign at totalviewtech.com>
To:
Kendrick Wong/Toronto/IBM at IBMCA
Cc:
Jason Merrill <jason at redhat.com>, dwarf-discuss at lists.dwarfstd.org
Date:
21/08/2008 04:09 PM
Subject:
Re: [Dwarf-Discuss] name lookup w/ using directives



I don't know what the right answer is here, but I can tell you what we do 
in TotalView.

The DWARF information, is translated to our internal symbol table format 
during what we call "incorporation" time. The symbol table incorporators 
build data structures that are pretty much language neutral, but the 
incorporators do in many cases do have to know about language, the 
compiler vendor, and sometimes even compiler version. In a prefect world, 
we wouldn't need to know so much about what individual compilers and 
compiler versions do, but since we live on Earth, we do.

Anyway, as I said, the symbol table incorporators build data symbol table 
structures that are pretty much language neutral, but each file scope 
knows its language (C, C++, Fortran 77, Fortran 9x, Assembler, etc.), and 
most symbols are descendants of file scopes. When symbol table lookups 
happen, they use the language rules of the language for the enclosing 
lookup scope. In fact, the debugger core client code calls a method named 
"find_by_language_rules", which delegates to language-specific lookup 
functions like "find_by_cplus_language_rules", 
"find_by_f9x_language_rules", etc.

So, I think that it's not true that we need a different tag for the C++ 
using directive. The fact that the DWARF tag is doing double duty for 
C++/Fortran doesn't really matter to TotalView, and TotalView gets it all 
correct today. What really matters to us is getting accurate compilation 
unit language and compiler vendor/version information. If we have that, we 
can work out the semantics of what a particular tag, such as 
DW_TAG_imported_module, means.

Cheers, John D.


Kendrick Wong wrote:
> 
> Jason wrote:
>> The DWARF has the same nesting information as the source code; the
>> consumer can use the same algorithm as the compiler.  I don't think we
>> want to encode standard lookup rules in the debugging information;
>> better to put that in one place in the debugger rather expand the
>> debugging information for every occurrence of a using-declaration.
> 
> I still have some reservation about building dependencies on the C++
> language rules into DWARF.  All of the other TAGs that I am aware of,
> are language independent, so a DWARF consumer don't have to worry about
> the language and still be able to interpret the DWARF data correctly.
> 
> The DW_TAG_imported_module seems to break this rule.  For Fortran, the
> namespace is imported immediately.  For C++, the namespace is imported
> at a later time, not to mention all the other intricacies regarding
> common enclosing scope.  From this point of view, I really think C++
> using directive needs a different tag.
> 
> Thanks,
> Regards,
> ------------------------------------------------------------------------
> Kendrick Wong
> z/OS C/C++ Compiler
> Common Debug Architecture
> C2/YGK/8200/MKM *
> kendrick at ca.ibm.com*
> Office:*905-413-2865* Fax:*905-413-4839* Tie:*313-2865*
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20080821/2a412cf1/attachment.htm>