 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / June 2006dumpbin un-undecorate
According to dumpbin, my extern "C" __stdcall'ed functions are not decorated... According to depends they are not decorated... According to the documentation, (and previous releases of vc++), they should be... Is this expected? I know extern "C" should imply no name decorating but its never been the case before. Thanks > According to dumpbin, my extern "C" __stdcall'ed functions are not > decorated... According to depends they are not decorated... According to [quoted text clipped - 5 lines] > I know extern "C" should imply no name decorating but its never been the > case before. Yes, this is to be expected. If you read the MSDN docs, for extern "C" and, you'll find that it will explicitly create unmangled names. http://msdn2.microsoft.com/en-us/library/wf2w9f6x.aspx extern "C" has always done this for me, so if it didn't for you, there was probably another problem.  SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" > Yes, this is to be expected. > If you read the MSDN docs, for extern "C" and, you'll find that it will [quoted text clipped - 3 lines] > extern "C" has always done this for me, so if it didn't for you, there was > probably another problem. Can you help me debug this then please: C:\work\dll>cat dll.cpp extern "C" __declspec(dllexport) int __stdcall fndll(void); // This is an example of an exported function. extern "C" __declspec(dllexport) int __stdcall fndll(void) { return 42; } C:\work\dll>cl /LD dll.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. dll.cpp Microsoft (R) Incremental Linker Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. /out:dll.dll /dll /implib:dll.lib dll.obj Creating library dll.lib and object dll.exp C:\work\dll>dumpbin /exports dll.dll Microsoft (R) COFF/PE Dumper Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file dll.dll File Type: DLL Section contains the following exports for dll.dll 00000000 characteristics 448F1D09 time date stamp Tue Jun 13 13:16:09 2006 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 _fndll@0 [snipped] >> Yes, this is to be expected. >> If you read the MSDN docs, for extern "C" and, you'll find that it will [quoted text clipped - 15 lines] > return 42; > } It seems this is one of those occasions where my understanding does not live up to reality. what I said was true only for __cdecl. in that case, cpp functions are decorated unless declared with extern "C" I always use __cdecl because you can use it for all types of functions. varargs functions cannot have __stdcall because the callee is supposed to remove parameters from the stack. it can only do this if it knows in advance which parameters it will get. for varargs functions, it obviously does not know this. Anyways, if you add a DEF file to your dll project, you don't need the extern "C" __declspec(dllexport) keywords. Adding this to your def file is enough to export functions and prevent name decoration: EXPORTS fndll @1 apologies for the confusion. SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" > extern "C" has always done this for me, so if it didn't for you, there was > probably another problem. For completeness (vs 2k5): C:\TEMP>cl /LD dll.cpp Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for x64 Copyright (C) Microsoft Corporation. All rights reserved. dll.cpp Microsoft (R) Incremental Linker Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. /out:dll.dll /dll /implib:dll.lib dll.obj Creating library dll.lib and object dll.exp C:\TEMP>dumpbin /exports dll.dll Microsoft (R) COFF/PE Dumper Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file dll.dll File Type: DLL Section contains the following exports for dll.dll 00000000 characteristics 448F1DD6 time date stamp Tue Jun 13 13:19:34 2006 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 fndll [snipped] "Sean Connery" <SeanConnery@discussions.microsoft.com> wrote in message news:BC5391D2-ABD9-4F08-8B79- > 1 0 00001000 fndll Yep, that looks like a bug. __stdcall functions should be named according to the __stdcall naming convention (which has nothing to do with C++ name decoration): _{name}@{total-params-size-bytes). I'm sure you can get the right name by using a DEF file for the linker, but IMO you shouldn't need to. -cd > "Sean Connery" <SeanConnery@discussions.microsoft.com> wrote in message > news:BC5391D2-ABD9-4F08-8B79- [quoted text clipped - 7 lines] > I'm sure you can get the right name by using a DEF file for the linker, but > IMO you shouldn't need to. So is this a new bug or a bug that was fixed... And if its new, who do I tell? >> 1 0 00001000 fndll > [quoted text clipped - 4 lines] > I'm sure you can get the right name by using a DEF file for the linker, > but IMO you shouldn't need to. confusion ensues... I just replied to the previous mail that my original assertion was wrong. extern "C" only has effect on __cdecl declarations, as is documented in MSDN. My bad. I also told the OP that you can use a DEF file to get undecorated names. so far so good. but I did check with vs2k5 that this extern "C" __declspec(dllexport) int __stdcall fndll(void); results in _fndll@0 which is what it should be (although a warning about unused extern "C: would have been nice) So if the OP gets a function name 'fndll' instead of a decorated name, he is doing something else. OP, did you change anything? because this: extern "C" __declspec(dllexport) int __stdcall fndll(void); // This is an example of an exported function int __stdcall fndll(void) { return 42; } results in the correct (decorated) name _fndll@0 SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" > but I did check with vs2k5 that this > extern "C" __declspec(dllexport) int __stdcall fndll(void); [quoted text clipped - 14 lines] > } > results in the correct (decorated) name _fndll@0 This is not the sample I posted though. I posted: extern "C" __declspec(dllexport) int __stdcall fndll(void); extern "C" __declspec(dllexport) int __stdcall fndll(void) { return 42; } Notice extern"C" on declaration and definition. I don't know why your sample excludes it from the definition. >> extern "C" __declspec(dllexport) int __stdcall fndll(void); >> // This is an example of an exported function [quoted text clipped - 12 lines] > return 42; > } Because it doesn't matter. it is something I did to see if this could cause your problem. The extern "C" __declspec(dllexport) is only needed for the declaration. the definition doesn't need it. i always leave it behind in the implementation to improve readability. SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" > confusion ensues... Lets add more confusion: C:\test>cat dll1.cpp extern "C" __declspec(dllexport) int __stdcall fndll(void); int __stdcall fndll(void) {return 42;} C:\test>cl /LD dll1.cpp [snip] dll1.cpp [snip] /out:dll1.dll C:\test>dumpbin /exports dll1.dll [snip] 1 0 00001000 fndll [snip] Now wth is going on >> confusion ensues... > [quoted text clipped - 18 lines] > > Now wth is going on Do you have a .DEF file in the same directory? The linker may look for it even when you don't specify it on the command-line. Also check the date on your DLL, to make sure it is rebuilt. > Do you have a .DEF file in the same directory? The linker may look for it > even when you don't specify it on the command-line. Also check the date on > your DLL, to make sure it is rebuilt. Nope no def file, just did a clean build on vs2k5, and lo and behold, its undecorated. > Lets add more confusion: > [quoted text clipped - 16 lines] > > Now wth is going on I just repeated exactly this, and I got the name "_fndll@0". Maybe the cl.exe on your path doesn't point to the latest version of the VC++ compiler. When you type cl in the command line, what is the exact text that you get (including version number)? If it's not 14.something, it's not VC++ 2005 that you're running. Just trying to verify this, because you're apparently experiencing an odd problem that no one else can reproduce. I know for a fact that the Borland compiler recognizes extern "C" with __stdcall. It removes all decorations, regardless the calling convention. I also know that VC++ doesn't do that with __stdcall, unless you specify a DEF file. Are you sure that you're not using a DEF file? Tom > I just repeated exactly this, and I got the name "_fndll@0". Actually, as it turns out, I was using using VC++ 2003. When I type in cl, it shows version "13.10". If I explicitly cd to the C:\Program Files\Microsoft Visual Studio 8\VC\bin\ directory, trying to execute cl.exe from there, nothing happens, it simply doesn't work. I don't know why that happens, but I seem to be unable to execute the VC++ 2005 compiler from my command line (this computer is old and has VS2003 and used to have VS2005 Beta2 as well). So I can't try your example exactly as it is. Maybe someone with a working cl version "14.xxx" can confirm this. Tom > So I can't try your example exactly as it is. Maybe someone with a > working cl version "14.xxx" can confirm this. I've done this about 300 times today :) Slight exaggeration, but still, I'm convinced that the behaviour is atleast inconsistent with previous releases of visual C++ (atleast vs2k3) >> So I can't try your example exactly as it is. Maybe someone with a >> working cl version "14.xxx" can confirm this. > > I've done this about 300 times today :) Slight exaggeration, but > still, I'm convinced that the behaviour is atleast inconsistent with > previous releases of visual C++ (atleast vs2k3) It does seem that something must be amiss with your VC2005 installation. What edition (Express, Standard, etc.) of VC++ do you have installed? I just tried your repro and here's what I get: <code> // ext0613.cpp extern "C" __declspec(dllexport) int __stdcall fndll(void); // This is an example of an exported function. extern "C" __declspec(dllexport) int __stdcall fndll(void) { return 42; } </code> <output> >cl /LD ext0613.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. ext0613.cpp Microsoft (R) Incremental Linker Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. /out:ext0613.dll /dll /implib:ext0613.lib ext0613.obj Creating library ext0613.lib and object ext0613.exp >dumpbin /exports ext0613.dll Microsoft (R) COFF/PE Dumper Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file ext0613.dll File Type: DLL Section contains the following exports for ext0613.dll 00000000 characteristics 448F58BB time date stamp Tue Jun 13 17:30:51 2006 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 _fndll@0 Summary 2000 .data 2000 .rdata 1000 .reloc 7000 .text </output> I'm using VS2005 Team Suite edition. -cd > I've done this about 300 times today :) Slight exaggeration, but still, I'm > convinced that the behaviour is atleast inconsistent with previous releases > of visual C++ (atleast vs2k3) I thought someone else other than you. :-) When I use the VC++ 2005 IDE to create a new default Win32 DLL project and add your code, it generates the name _fndll@0, unless I explicitly create a DEF file with the undecorated name. I would be surprised if the command line compiler behaves differently, but I can't verify that. Again, my command line compiler currently only works with VC++ 2003. Tom >> I've done this about 300 times today :) Slight exaggeration, but >> still, I'm convinced that the behaviour is atleast inconsistent with [quoted text clipped - 6 lines] > compiler behaves differently, but I can't verify that. Again, my > command line compiler currently only works with VC++ 2003. The command-line compiler behaves the same (as it must, since it is the same). I can think of only two things that might explain what the OP is seeing: 1. It's specific to some edition of VC++ (e.g. Express). 2. Something's messed up in the OP's installation. -cd Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.