Enumerate all (unused) extern types

Question

Hi,

I am quite new to using Phoenix, and what I want to do is enumerating all (especially unused) types that have been #included in a unit of a C++ program. My first idea was to take an example pass and using moduleUnit.TypeTable.AllTypes in a PostPassEvent. However, this type table seems only to include types that are actually used - is my observation correct? The symbol table behaves quite similar.

Therefore, my question is how I would get all types/functions that are declared (extern) in the unit, regardless of whether they are used or not.

Additionally, are there special requirements on how I must use the compiler? Currently, I am compiling an already pre-processed C++ file with /Od. Is this sufficient?

Best regards,
Christoph

Answer 1

For types, you should make sure to pass one of the debugging options (/Zi or /Z7). But let me warn you that there are challenges.

Historically the compiler backend (c2) has not required access to user-level type information and so the type descriptions available to it are quite limited. So even though Phoenix has a rich type system c2 does not build very interesting types. We have changes for that in our code base now (so-called typed IL or rich types) but my recollection is that the CTP code does not contain this support.

Even with typed IL in place, my recollection is that the frontend will not emit types into the PDB (under /Zi) or the type blob passed to c2 (under /Z7) that are not referenced in compilation, so there will be types missing.

Functions declared extern you should be able to see without trouble; just walk the module unit symbol table and look for function symbols with visibility GlobalReference.

---

Architect - Microsoft Phoenix Project

Answer 2

Hi Andy,

thanks for the quick response.

Even with typed IL in place, my recollection is that the frontend will not emit types into the PDB (under /Zi) or the type blob passed to c2 (under /Z7) that are not referenced in compilation, so there will be types missing.

That is also my observation. Is there any chance to insert a plugin in an earlier phase where this information is still available (without writing an own C++ front end)? 

Functions declared extern you should be able to see without trouble; just walk the module unit symbol table and look for function symbols with visibility GlobalReference.

I have tested that, and as far as I can see, function prototypes are also only emitted if used. I created a single CPP with an empty main and included windows.h, but I cannot see any of the API functions. Only some stuff that seems to be used by CRT (about 10 functions).

Is my assumption correct that the missing type problem will not be solved by your "richt types"? As I understand, this will just give me more information about the types that are used, right? Nevertheless, second question: Can you give me any hint on whether there will be a new CTP including rich types in the near future?

Best regards,
Christoph

Answer 3

The compiler tries to keep the number of functions in the object files to a minimum. This happens both in c1 (frontend) and in c2. I repeated your experiment and get a similar small set:

C:\home>cl -nologo -c -Zi hello.cpp -d2symdumpcil:1 | findstr Function
SymbolTable for Function _main (State: Hir)
Function LocID=21 ExtID=3830 _main : GlobalDefinition CDecl.Function(i32,up32->up
Function LocID=36 ExtID=3292 _fgetwc : GlobalReference CDecl.Function(up32->Aggre
Function LocID=52 ExtID=2933 _printf : GlobalReference CDecl.Function(up32->i8,..
Function LocID=91 ExtID=3512 __vswprintf_c_l : GlobalReference CDecl.Function(up
Function LocID=124 ExtID=3565 __vswprintf : GlobalReference CDecl.Function(up32->
Function LocID=128 ExtID=2786 ___iob_func : GlobalReference CDecl.Function()->(up
Function LocID=144 ExtID=3297 _fputwc : GlobalReference CDecl.Function(u16,up32->
Function LocID=157 ExtID=3574 ___vswprintf_l : GlobalReference CDecl.Function(up3

You are correct that "rich types" will not alter this behavior, just give better descriptions of the types c2 does see. And there is no way to plug into c1 to see the full set of parsed declarations; it is not extensible like c2 is.

As far as when we might have a new CTP, I can't make any promises...

---

Architect - Microsoft Phoenix Project