2

I have a section of C++ code in MSVC2010 that creates a DLL wrapper. The section of code looks something like this...

extern "C" __declspec(dllexport) DWORD myDllExportFunction()
{
    return (DWORD)SomeFunction(SomeParameter);
}

or...

_declspec(dllexport) int64 _stdcall myDllExportFunction2(<someType> someParameter){
{
    return new (DWORD)SomeExternalFunction(SomeParameter);
}

I would expect my exports section from doing a dumpbin on this dll to contain just the fully qualified function name however it looks more like this.

 _myDllExportFunction@12 = _myDllExportFunction@12

I have no idea why this equal sign is there or what it means. I have a strong feeling that the function is not accessible by programs which import the dll as it is not doing what it is supposed to.

for sake of providing enough information I have included some of my compiler and linker switches

Compiler Options:

/Zi /nologo /Wall /WX- /O2 /Ob2 /Oi /Oy- /D "_WINDLL" /D "_MBCS" /D "_AFXDLL" /Gm- /EHsc /GS /fp:precise /Zc:wchar_t /Zc

Linker Options:

/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\....\MyProj.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /PGD:"C:\....\MyProj.pgd" /TLBID:1 /DYNAMICBASE:NO /NXCOMPAT:NO /IMPLIB:"MyProj.lib" /MACHINE:X86 /ERRORREPORT:QUEUE

Note: /IMPLIB:"MyProj.lib" -> This import library has all of the exports that I want to have in my DLL in the format that I want them to be in the dll.

Is there any setting in my projects options that would cause this? Was there any changes to dllexport in the past years that I might have missed? Is there any information that I could provide you that would help you understand my problem?

Satyrn
  • 63
  • 7

4 Answers4

2

Try turning off debug information generation.

enter image description here

John Dibling
  • 99,718
  • 31
  • 186
  • 324
0

You have mangled the name by declaring it __stdcall, presumably in a separate declaration. You must give it the __cdecl calling convention to avoid name mangling.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • `__cdecl` doesn't avoid name mangling, it just changes the rules. – Ben Voigt Sep 30 '11 at 17:43
  • @BenVoigt This actually appeared to remove the mangling when I tried this, however I did not ask to remove the mangling (I still wanted to see). – Satyrn Sep 30 '11 at 18:25
  • @Ben: It can effect name mangling: http://msdn.microsoft.com/en-us/library/x7kb4e2f.aspx – John Dibling Sep 30 '11 at 19:04
  • I mean, im looking right at a project that I've been building minute after minute, and it does for me. I think that's proof enough. It seems that it only removes name mangling if it is defined `extern "C" __declspec(dllexport) __cdecl functionName(functionParams)` not possitive but I think `extern "C"` combined with this is what is removing the mangling. – Satyrn Sep 30 '11 at 19:11
  • It changes the mangling rules. With `extern "C" __cdecl`, the only mangling is adding a leading underscore. On x86, anyway. – Ben Voigt Sep 30 '11 at 19:47
0

If you want to control the names of exported functions (for example, to remove mangling), you'll need to use a linker module definition (.def) file.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • I dont need to remove name mangling, however I have tried this and I get linker errors which makes me thing that it is not finding these methods in my C classes. Here is an example of the def file... [code]LIBRARY myProjectname EXPORTS "myDllExportFunction@12"[/code] – Satyrn Sep 30 '11 at 17:54
  • @Satyrn: Just put the function name into the .def file, like `LIBRARY myProjectname EXPORTS myDllExportFunction`. No quotes, no stack size annotation. You might possibly need `EXPORTS myDllExportFunction = _myDllExportFunction@12`, but usually the linker figures that out. Do pay attention to leading underscores. – Ben Voigt Sep 30 '11 at 18:08
  • I found the solution in another persons answer, however just simply trying to use a def file gives me LNK2001 errors "unresolved external symbol" and I dont particularly know why. I removed the name mangling in the def files for each of my functions. – Satyrn Sep 30 '11 at 18:15
0

There are a few different options to prevent name mangling.

  • Change the declaration specifier for the exported function from __stdcall to __cdecl. So the function signature should look like this

    extern "C" DWORD __declspec(dllexport) __cdecl myDllExportFunction()

If you must use the __stdcall calling convention use one of the following two methods to get around name mangling. In both cases you do not need to add __declspec(dllexport) to the function definition (but it's OK if you do).

  • Add a .def file to the project containing the lines

LIBRARY YourLibraryName
EXPORTS
    myDllExportFunction

  • In the project properties, go to Linker -> Command Line and in the edit box for Additional Options add /export:myDllExportFunction
Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • I think the list of exported functions goes under the `EXPORTS` keyword, not on the same line. And `__cdecl` function names will still be mangled with a leading underscore. – Ben Voigt Sep 30 '11 at 18:11
  • @BenVoigt Thanks, you're right about the def file syntax. But `__cdecl` function names are not mangled with a leading underscore, I've got a working project open in front of me that proves otherwise. – Praetorian Sep 30 '11 at 18:16
  • x86 or x64. That changes the rules too. http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows – Ben Voigt Sep 30 '11 at 19:48
  • @BenVoigt It's an x86 C project compiled with VS2005. No mangling happens unless I change the calling convention to `__stdcall`; I don't know why Wikipedia is saying what it is. – Praetorian Sep 30 '11 at 20:20
  • @BenVoigt Dependency walker, I have the option "Undecorate C++ Functions" unchecked, but I suppose it might be stripping the leading underscore – Praetorian Sep 30 '11 at 21:02
  • Ok, it looks like the actual symbol in the .obj file has a leading underscore, but the DLL export table doesn't (checked with Dependency Walker, `dumpbin`, and the VS binary editor). I think this has changed though, with different versions of Visual C++. In contrast, for `__stdcall`, the exported name is identical to the symbol name. – Ben Voigt Sep 30 '11 at 21:07
  • @BenVoigt Thanks for digging into that, you had me puzzled for a while – Praetorian Sep 30 '11 at 21:17