dumpbin un-undecorate

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
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.
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno van Dooren said:
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.
Click to expand...

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]
 
Bruno van Dooren said:
extern "C" has always done this for me, so if it didn't for you, there was
probably another problem.
Click to expand...

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 said:
1 0 00001000 fndll
Click to expand...

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
 
Yes, this is to be expected.
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;
}
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Carl Daniel said:
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.
Click to expand...

So is this a new bug or a bug that was fixed... And if its new, who do I tell?
 
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.
Click to expand...

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

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno van Dooren said:
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
Click to expand...

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.
 
Bruno van Dooren said:
confusion ensues...
Click to expand...

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
 
Sean Connery said:
Bruno van Dooren said:
confusion ensues...
Click to expand...

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
Click to expand...

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.
 
Ben Voigt said:
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.
Click to expand...

Nope no def file, just did a clean build on vs2k5, and lo and behold, its
undecorated.
 
Sean said:
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
Click to expand...

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
 
Tamas said:
I just repeated exactly this, and I got the name "_fndll@0".
Click to expand...

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.
Click to expand...

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)
 
Sean said:
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)
Click to expand...

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>

cl /LD ext0613.cpp
Click to expand...
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
Click to expand...
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
 
Sean said:
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)
Click to expand...

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
 
Tamas said:
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.
Click to expand...

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
 
extern "C" __declspec(dllexport) int __stdcall fndll(void);
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;
}
Click to expand...

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.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Back
Top