c - Generating correct .DEF files to export non-static functions AND GLOBALS -

following on a question detecting bad linkage globals across dll boudaries, turns out need modify .def file generator tool used postgresql project correctly emits data tags .def entries global variables.

problem

i can't seem find way, using microsoft's tools, symbol table listing differentiates between global variables , functions, , includes globals aren't initialized @ definition site.

ideas?

broken current approach

the tool loops on dumpbin /symbols output generate .def file. unlike nm, i'm used to, dumpbin /symbols not appear emit entry each symbol indicate symbol type - function, initialized variable, uninitialized variable. shows whether symbol locally defined or not.

with each dumpbin output line followed corresponding definition in .c file, have first initialized global:

00b 00000000 sect3  notype       external     | _defaultxactisolevel int         defaultxactisolevel = xact_read_committed; 

vs function non-static linkage:

022 00000030 sect5  notype ()    external     | _isabortedtransactionblockstate bool isabortedtransactionblockstate(void) {...} 

... , bonus fun, un-initialized globals appear shown undef, references symbols other compilation units, e.g:

007 00000004 undef  notype       external     | _xactisolevel int         xactisolevel; 

even though pre-declared in header during compilation (with project specific macro hand expanded readability) as:

extern __declspec(dllexport) int xactisolevel; 

so... looks dumpbin output doesn't contain enough information generate correct .def file.

right gendefs.pl merrily spitting out .def file omits globals aren't initialized, , declares else code (by failing specify constant or data in .def). broken, it's worked remarkably well.

fixing it

to produce correct .def files, need way determine symbols variables.

i looked @ using cl.exe's /fm option, it's passthrough linker's /map option, , nothing when you're generating object file, not linking it.

i use symbol dump tool produces more useful information gcc's nm.exe, adds tool dependencies , seems fragile.

at point not able annotate every exported function pgdllimport (the __declspec(dllimport) / __declspec(dllexport) macro used project) , stop using def file.

even if need find approach cause clear linker errors when pgdllimport omitted on exposed variable.

so. windows linker/compiler experts. ideas?

well, must wrong saying microsoft tools doesn't use symbol type field @ all.

1). cl doesn't use differentiate actual type info, stores information need:

• 0x20 means function
• 0x00 means not function

pe/coff specification, p. 46-47.

you may search presence/abscence of () after symbol type (notype in case) in dumpbin's output find whether code or data.

2). also, cl generates in obj files special section linker include export switch every __declspec(dllexport) symbol in form /export:symbol[,type].

3). , last, can specify 'c++' external linkage , symbols' types because of mangling.