Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

name decoration issue in DLL

286 views
Skip to first unread message

George

unread,
Oct 5, 2008, 6:55:00 AM10/5/08
to
Hello everyone,


I think extern C is enough to prevent name from decorated, but when we
export function names from a DLL using dllexport, even if we declare at the
same time with extern C, but without a DEF file to define un-decorated
exported function names, the name is still decorated.

I do not know why DEF file is needed? extern C is not enough to control name
decoration for both DLL exported names and current DLL model linking?


regards,
George

Igor Tandetnik

unread,
Oct 5, 2008, 8:45:43 AM10/5/08
to
"George" <Geo...@discussions.microsoft.com> wrote in message
news:34A5288E-A619-4132...@microsoft.com

> I think extern C is enough to prevent name from decorated, but when we
> export function names from a DLL using dllexport, even if we declare
> at the same time with extern C, but without a DEF file to define
> un-decorated exported function names, the name is still decorated.

There are two mechanisms in play here: C++ name mangling, and C name
decoration. Name mangling encodes function signature (parameter and
return types) into exported name, which allows overloaded functions to
have distinct names for linkage purposes. Name decoration depends only
on the function's calling convention; e.g. __stdcall functions normally
get exported as _FunctionName@XX (where XX is the total size of
parameters).

extern "C" suppresses name mangling, but not name decoration. To
suppress the latter, one must use DEF file.

> I do not know why DEF file is needed? extern C is not enough to
> control name decoration for both DLL exported names and current DLL
> model linking?

Obviously not, or you wouldn't be here asking this question.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


George

unread,
Oct 5, 2008, 8:55:01 AM10/5/08
to
Thanks Igor!


Your reply is excellent. I have tried but have different results from well
documented rules of MSDN.

In the document,

http://msdn.microsoft.com/en-us/library/x7kb4e2f.aspx

it is mentioned default calling convention is __cdecl, and the resulting
name in DLL should begin with sign _.

But my result is the default calling convention __cdecl results in name
without _ sign? Here is my code and my output. Any ideas?

I am using VS 2008, Debug build for Win32.

D:\Visual Studio 2008\Projects\TestDll2\Debug>dumpbin /exports TestDll2.dll
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file TestDll2.dll

File Type: DLL

Section contains the following exports for TestDll2.dll

00000000 characteristics
48E8B6E6 time date stamp Sun Oct 05 20:45:26 2008
0.00 version
1 ordinal base
2 number of functions
2 number of names

ordinal hint RVA name

1 0 000110AF MyFunc1 = @ILT+170(_MyFunc1)
2 1 0001106E _MyFunc2@4 = @ILT+105(_MyFunc2@4)

Summary

1000 .data
1000 .idata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
10000 .textbss


extern "C"
{
__declspec (dllexport) int MyFunc1 (int A) {return 100;}
__declspec (dllexport) int __stdcall MyFunc2 (int A) {return 100;}
}


regards,
George

George

unread,
Oct 6, 2008, 7:26:10 AM10/6/08
to
Hi Igor,


I did some research today and find it is maybe under __cdecl mode, compiler
removes the _ leading sign of function symbol name. And it seems a bug of the
MSDN page, which said __cdecl names begins with _ sign?

http://msdn.microsoft.com/en-us/library/x7kb4e2f.aspx

But I am not 100% sure about it. It is appreciated if you could share some
ideas.


regards,
George

Norbert Unterberg

unread,
Oct 6, 2008, 1:45:43 PM10/6/08
to

George schrieb:

> I did some research today and find it is maybe under __cdecl mode, compiler
> removes the _ leading sign of function symbol name. And it seems a bug of the
> MSDN page, which said __cdecl names begins with _ sign?

No you are wrong. The compiler does decorate the function name with the "_"
sign. Nevertheless, you do not need a DEF file.

The following DLL:

extern "C"
__declspec(dllexport) int __stdcall ExportStdcall(int a)
{
return 3;
}

extern "C"
__declspec(dllexport) int __cdecl ExportCdecl(int a)
{
return 4;
}


produces the follwing entries in the export table:

Exports

ordinal name

1 _ExportCdecl
exported name: ExportCdecl
2 _ExportStdcall@4

So the compiler actually adds and preserves the "_" sign, but the linker adds
the undecorated name to the DLL's export table and so makes it available to
GetProcAddress.

Norbert

Norbert Unterberg

unread,
Oct 6, 2008, 1:49:12 PM10/6/08
to

Igor Tandetnik schrieb:

> extern "C" suppresses name mangling, but not name decoration. To
> suppress the latter, one must use DEF file.

Wrong. I did not need a DEF file since __declspec(dllexport).
__declspec(dllexport) on __cdecl functions automatically adds the undecorated
function name to the export table.

Norbert

Igor Tandetnik

unread,
Oct 6, 2008, 7:20:07 PM10/6/08
to

Most of the time, you would want to export __stdcall functions though.
Otherwise your DLL cannot be consumed from, say, VB.

George

unread,
Oct 7, 2008, 2:44:00 AM10/7/08
to
Thanks Igor,


I agree.


regards,
George

George

unread,
Oct 7, 2008, 2:48:00 AM10/7/08
to
Thanks Norbert,


I agree. I think extern C only make C++ name mangling to C name mangling,
and it never controls DLL exported function name -- DEF is used to control it.

If not using DEF file, internal name, either C decoration style or C++
decoration style will be used as names exported from DLL.

Are they correct understanding?


regards,
George

George

unread,
Oct 7, 2008, 2:50:01 AM10/7/08
to
Thanks Norbert,


> Exports
>
> ordinal name
>
> 1 _ExportCdecl
> exported name: ExportCdecl
> 2 _ExportStdcall@4

Where do you get the export table? From dumpbin /exports?


regards,
George

Norbert Unterberg

unread,
Oct 7, 2008, 7:24:29 AM10/7/08
to
George schrieb:

That's from the map file.

George

unread,
Oct 8, 2008, 3:58:00 AM10/8/08
to
Thanks Norbert,


Here is the content of the source file of the dll, maindll.cpp and my map
file content, it does not contain information about an export section as you
mentioned before.

Anything wrong with my environment? I am using VC 2008.

--------------------
maindll.cpp

extern "C"
{
__declspec (dllexport) int MyFunc1 (int A) {return 100;}
__declspec (dllexport) int __stdcall MyFunc2 (int A) {return 100;}
}


TestDll2

Timestamp is 48ec66ca (Wed Oct 08 15:52:42 2008)

Preferred load address is 10000000

Start Length Name Class
0001:00000000 00010000H .textbss DATA
0002:00000000 000032ceH .text CODE
0003:00000000 00000104H .CRT$XCA DATA
0003:00000104 00000104H .CRT$XCZ DATA
0003:00000208 00000104H .CRT$XIA DATA
0003:0000030c 00000104H .CRT$XIAA DATA
0003:00000410 00000104H .CRT$XIZ DATA
0003:00000520 00000a26H .rdata DATA
0003:00000f48 00000163H .rdata$debug DATA
0003:000010ac 00000104H .rtc$IAA DATA
0003:000011b0 00000104H .rtc$IMZ DATA
0003:000012b4 00000104H .rtc$IZZ DATA
0003:000013b8 00000104H .rtc$TAA DATA
0003:000014bc 00000104H .rtc$TMZ DATA
0003:000015c0 00000104H .rtc$TZZ DATA
0003:000016c8 000001c2H .xdata$x DATA
0003:00001890 0000016eH .edata DATA
0004:00000000 00000133H .data DATA
0004:00000138 0000043cH .bss DATA
0005:00000000 00000028H .idata$2 DATA
0005:00000028 00000014H .idata$3 DATA
0005:0000003c 00000130H .idata$4 DATA
0005:0000016c 00000130H .idata$5 DATA
0005:0000029c 000004c5H .idata$6 DATA

Address Publics by Value Rva+Base Lib:Object

0000:00000000 ___safe_se_handler_table 00000000 <absolute>
0000:00000000 ___safe_se_handler_count 00000000 <absolute>
0000:00000000 ___ImageBase 10000000 <linker-defined>
0001:00000000 __enc$textbss$begin 10001000 <linker-defined>
0001:00010000 __enc$textbss$end 10011000 <linker-defined>
0002:00000310 _MyFunc1 10011310 f maindll.obj
0002:00000350 _MyFunc2@4 10011350 f maindll.obj
0002:00000390 __RTC_InitBase 10011390 f
MSVCRTD:_init_.obj
0002:000003d0 __RTC_Shutdown 100113d0 f
MSVCRTD:_init_.obj
0002:00000490 __CRT_INIT@12 10011490 f
MSVCRTD:crtdll.obj
0002:00000860 _NtCurrentTeb 10011860 f i
MSVCRTD:crtdll.obj
0002:00000870 __DllMainCRTStartup@12 10011870 f
MSVCRTD:crtdll.obj
0002:00000af0 __RTC_NumErrors 10011af0 f
MSVCRTD:_userapi_.obj
0002:00000b00 __RTC_GetErrDesc 10011b00 f
MSVCRTD:_userapi_.obj
0002:00000b20 __RTC_SetErrorType 10011b20 f
MSVCRTD:_userapi_.obj
0002:00000b50 __RTC_SetErrorFunc 10011b50 f
MSVCRTD:_userapi_.obj
0002:00000b80 __RTC_SetErrorFuncW 10011b80 f
MSVCRTD:_userapi_.obj
0002:00000bb0 ?_RTC_GetErrorFunc@@YAP6AHHPBDH00ZZPBX@Z 10011bb0 f
MSVCRTD:_userapi_.obj
0002:00000bc0 ?_RTC_GetErrorFuncW@@YAP6AHHPB_WH00ZZPBX@Z 10011bc0 f
MSVCRTD:_userapi_.obj
0002:00000bc6 __CRT_RTC_INITW 10011bc6 f
MSVCRTD:MSVCR90D.dll
0002:00000bd0 ___clean_type_info_names 10011bd0 f
MSVCRTD:tncleanup.obj
0002:00000bf0 __onexit 10011bf0 f
MSVCRTD:atonexit.obj
0002:00000d40 _atexit 10011d40 f
MSVCRTD:atonexit.obj
0002:00000d70 __RTC_Initialize 10011d70 f
MSVCRTD:_initsect_.obj
0002:00000da0 __RTC_Terminate 10011da0 f
MSVCRTD:_initsect_.obj
0002:00000dd0 __encode_pointer 10011dd0 f
MSVCRTD:MSVCR90D.dll
0002:00000dd6 __malloc_dbg 10011dd6 f
MSVCRTD:MSVCR90D.dll
0002:00000ddc __free_dbg 10011ddc f
MSVCRTD:MSVCR90D.dll
0002:00000de2 __encoded_null 10011de2 f
MSVCRTD:MSVCR90D.dll
0002:00000de8 __decode_pointer 10011de8 f
MSVCRTD:MSVCR90D.dll
0002:00000dee __CrtSetCheckCount 10011dee f
MSVCRTD:MSVCR90D.dll
0002:00000e00 __ValidateImageBase 10011e00 f
MSVCRTD:pesect.obj
0002:00000e80 __FindPESection 10011e80 f
MSVCRTD:pesect.obj
0002:00000f20 __IsNonwritableInCurrentImage 10011f20 f
MSVCRTD:pesect.obj
0002:00001076 __initterm 10012076 f
MSVCRTD:MSVCR90D.dll
0002:0000107c __initterm_e 1001207c f
MSVCRTD:MSVCR90D.dll
0002:00001082 __amsg_exit 10012082 f
MSVCRTD:MSVCR90D.dll
0002:00001090 ___security_init_cookie 10012090 f
MSVCRTD:gs_support.obj
0002:000011a2 ___CppXcptFilter 100121a2 f
MSVCRTD:MSVCR90D.dll
0002:000011b0 _DllMain@12 100121b0 f
MSVCRTD:dllmain.obj
0002:000011e0 __except_handler4 100121e0 f
MSVCRTD:chandler4gs.obj
0002:00001220 _DebuggerKnownHandle 10012220 f
MSVCRTD:_error_.obj
0002:00001300 ?_RTC_Failure@@YAXPAXH@Z 10012300 f
MSVCRTD:_error_.obj
0002:000016d0 ?_RTC_StackFailure@@YAXPAXPBD@Z 100126d0 f
MSVCRTD:_error_.obj
0002:00001810 ?_RTC_AllocaFailure@@YAXPAXPAU_RTC_ALLOCA_NODE@@H@Z
10012810 f MSVCRTD:_error_.obj
0002:00001a20 __RTC_UninitUse 10012a20 f
MSVCRTD:_error_.obj
0002:00001b44 ___clean_type_info_names_internal 10012b44 f
MSVCRTD:MSVCR90D.dll
0002:00001b4a __unlock 10012b4a f
MSVCRTD:MSVCR90D.dll
0002:00001b50 ___dllonexit 10012b50 f
MSVCRTD:MSVCR90D.dll
0002:00001b56 __lock 10012b56 f
MSVCRTD:MSVCR90D.dll
0002:00001b5c __except_handler4_common 10012b5c f
MSVCRTD:MSVCR90D.dll
0002:00001b70 @__security_check_cookie@4 10012b70 f
MSVCRTD:secchk.obj
0002:00001b90 ?_RTC_GetSrcLine@@YAHPAEPA_WKPAH1K@Z 10012b90 f
MSVCRTD:_pdblkup_.obj
0002:00002150 ___report_gsfailure 10013150 f
MSVCRTD:gs_report.obj
0002:000022a2 __crt_debugger_hook 100132a2 f
MSVCRTD:MSVCR90D.dll
0002:000022a8 _InterlockedExchange@8 100132a8 f
kernel32:KERNEL32.dll
0002:000022ae _Sleep@4 100132ae f
kernel32:KERNEL32.dll
0002:000022b4 _InterlockedCompareExchange@12 100132b4 f
kernel32:KERNEL32.dll
0002:000022ba _QueryPerformanceCounter@4 100132ba f
kernel32:KERNEL32.dll
0002:000022c0 _GetTickCount@0 100132c0 f
kernel32:KERNEL32.dll
0002:000022c6 _GetCurrentThreadId@0 100132c6 f
kernel32:KERNEL32.dll
0002:000022cc _GetCurrentProcessId@0 100132cc f
kernel32:KERNEL32.dll
0002:000022d2 _GetSystemTimeAsFileTime@4 100132d2 f
kernel32:KERNEL32.dll
0002:000022d8 _DisableThreadLibraryCalls@4 100132d8 f
kernel32:KERNEL32.dll
0002:000022de _IsDebuggerPresent@0 100132de f
kernel32:KERNEL32.dll
0002:000022e4 _RaiseException@16 100132e4 f
kernel32:KERNEL32.dll
0002:000022ea _DebugBreak@0 100132ea f
kernel32:KERNEL32.dll
0002:000022f0 _WideCharToMultiByte@32 100132f0 f
kernel32:KERNEL32.dll
0002:000022f6 _MultiByteToWideChar@24 100132f6 f
kernel32:KERNEL32.dll
0002:000022fc _lstrlenA@4 100132fc f
kernel32:KERNEL32.dll
0002:00002302 _GetProcAddress@8 10013302 f
kernel32:KERNEL32.dll
0002:00002308 _LoadLibraryA@4 10013308 f
kernel32:KERNEL32.dll
0002:0000230e _HeapFree@12 1001330e f
kernel32:KERNEL32.dll
0002:00002314 _HeapAlloc@12 10013314 f
kernel32:KERNEL32.dll
0002:0000231a _GetProcessHeap@0 1001331a f
kernel32:KERNEL32.dll
0002:00002320 _GetModuleFileNameW@12 10013320 f
kernel32:KERNEL32.dll
0002:00002326 _VirtualQuery@12 10013326 f
kernel32:KERNEL32.dll
0002:0000232c _FreeLibrary@4 1001332c f
kernel32:KERNEL32.dll
0002:00002332 _TerminateProcess@8 10013332 f
kernel32:KERNEL32.dll
0002:00002338 _GetCurrentProcess@0 10013338 f
kernel32:KERNEL32.dll
0002:0000233e _UnhandledExceptionFilter@4 1001333e f
kernel32:KERNEL32.dll
0002:00002344 _SetUnhandledExceptionFilter@4 10013344 f
kernel32:KERNEL32.dll
0003:00000000 ___xc_a 10015000
MSVCRTD:cinitexe.obj
0003:00000104 ___xc_z 10015104
MSVCRTD:cinitexe.obj
0003:00000208 ___xi_a 10015208
MSVCRTD:cinitexe.obj
0003:00000410 ___xi_z 10015410
MSVCRTD:cinitexe.obj
0003:0000053c __pRawDllMain 1001553c
MSVCRTD:crtdll.obj
0003:0000053c __pDefaultRawDllMain 1001553c
MSVCRTD:crtdll.obj
0003:00000540
??_C@_0DA@FJPPCPEH@f?3?2dd?2vctools?2crt_bld?2self_x86?2c@ 10015540
MSVCRTD:crtdll.obj
0003:0000057c
??_C@_0BP@OGBCLIBO@Stack?5around?5_alloca?5corrupted?$AA@ 1001557c
MSVCRTD:_userapi_.obj
0003:000005a4
??_C@_0CK@CNLNOEPB@Local?5variable?5used?5before?5initi@ 100155a4
MSVCRTD:_userapi_.obj
0003:000005d8 ??_C@_0BI@CIGMDCBH@Stack?5memory?5corruption?$AA@
100155d8 MSVCRTD:_userapi_.obj
0003:000005f4
??_C@_0CK@FEGOIOPB@Cast?5to?5smaller?5type?5causing?5los@ 100155f4
MSVCRTD:_userapi_.obj
0003:00000628 ??_C@_0BJ@HEGAHDFO@Stack?5pointer?5corruption?$AA@
10015628 MSVCRTD:_userapi_.obj
0003:00000660
?ProcessDetach@NativeDll@<CrtImplementationDetails>@@0IB 10015660
MSVCRTD:tncleanup.obj
0003:00000664
?ProcessAttach@NativeDll@<CrtImplementationDetails>@@0IB 10015664
MSVCRTD:tncleanup.obj
0003:00000668 ?ThreadAttach@NativeDll@<CrtImplementationDetails>@@0IB
10015668 MSVCRTD:tncleanup.obj
0003:0000066c ?ThreadDetach@NativeDll@<CrtImplementationDetails>@@0IB
1001566c MSVCRTD:tncleanup.obj
0003:00000670
?ProcessVerifier@NativeDll@<CrtImplementationDetails>@@0IB 10015670
MSVCRTD:tncleanup.obj
0003:00000674
??_C@_0BO@GNIAFIKK@Unknown?5Runtime?5Check?5Error?6?$AN?$AA@ 10015674
MSVCRTD:_error_.obj
0003:00000698
??_C@_0CM@NGINOKPC@Stack?5memory?5around?5_alloca?5was?5@ 10015698
MSVCRTD:_error_.obj
0003:000006cc
??_C@_0DG@HKJMLLLP@A?5local?5variable?5was?5used?5before@ 100156cc
MSVCRTD:_error_.obj
0003:0000070c
??_C@_0BN@FFOINMNJ@Stack?5memory?5was?5corrupted?6?$AN?$AA@ 1001570c
MSVCRTD:_error_.obj
0003:00000730
??_C@_0BBN@GPMLNJCF@A?5cast?5to?5a?5smaller?5data?5type?5ha@ 10015730
MSVCRTD:_error_.obj
0003:00000888
??_C@_0NN@NGPKDKPD@The?5value?5of?5ESP?5was?5not?5properl@ 10015888
MSVCRTD:_error_.obj
0003:00000a50
??_C@_0CA@IODNCDPG@Run?9Time?5Check?5Failure?5?$CD?$CFd?5?9?5?$CFs?$AA@
10015a50 MSVCRTD:_error_.obj
0003:00000a78 ??_C@_0BE@GNBOBNCK@Unknown?5Module?5Name?$AA@ 10015a78
MSVCRTD:_error_.obj
0003:00000a90 ??_C@_0BB@PFFGGCJP@Unknown?5Filename?$AA@ 10015a90
MSVCRTD:_error_.obj
0003:00000aa8
??_C@_1EA@NFKNIFJP@?$AAR?$AAu?$AAn?$AA?9?$AAT?$AAi?$AAm?$AAe?$AA?5?$AAC?$AAh?$AAe?$AAc?$AAk?$AA?5?$AAF?$AAa?$AAi?$AAl?$AAu?$AAr?$AAe?$AA?5?$AA?$CD?$AA?$CF?$AAd?$AA?5?$AA?9?$AA?5?$AA?$CF?$AAs?$AA?$AA@ 10015aa8 MSVCRTD:_error_.obj
0003:00000af8
??_C@_1GM@OLMCBDMB@?$AAR?$AAu?$AAn?$AAt?$AAi?$AAm?$AAe?$AA?5?$AAC?$AAh?$AAe?$AAc?$AAk?$AA?5?$AAE?$AAr?$AAr?$AAo?$AAr?$AA?4?$AA?6?$AA?$AN?$AA?5?$AAU?$AAn?$AAa?$AAb?$AAl?$AAe?$AA?5?$AAt?$AAo@ 10015af8 MSVCRTD:_error_.obj
0003:00000b7c
??_C@_0CG@IAFNJNEE@Stack?5corrupted?5near?5unknown?5var@ 10015b7c
MSVCRTD:_error_.obj
0003:00000bb0
??_C@_0EJ@LJKNEOLN@Stack?5area?5around?5_alloca?5memory@ 10015bb0
MSVCRTD:_error_.obj
0003:00000c08 ??_C@_08KJEDNCKC@?$CFs?$CFs?$CFs?$CFs?$AA@ 10015c08
MSVCRTD:_error_.obj
0003:00000c14 ??_C@_02LLMPMKNF@?$DO?5?$AA@ 10015c14
MSVCRTD:_error_.obj
0003:00000c18 ??_C@_01EEMJAFIK@?6?$AA@ 10015c18
MSVCRTD:_error_.obj
0003:00000c1c
??_C@_0BC@KIBAILCI@?$CFs?$CFs?$CFp?$CFs?$CFld?$CFs?$CFd?$CFs?$AA@ 10015c1c
MSVCRTD:_error_.obj
0003:00000c38
??_C@_0EI@CLEPFNGI@Stack?5area?5around?5_alloca?5memory@ 10015c38
MSVCRTD:_error_.obj
0003:00000c90 ??_C@_0N@MHFFIMFG@?6Address?3?50x?$AA@ 10015c90
MSVCRTD:_error_.obj
0003:00000ca0 ??_C@_07DFDJCKFN@?6Size?3?5?$AA@ 10015ca0
MSVCRTD:_error_.obj
0003:00000cac
??_C@_0CK@DKGBICFE@?6Allocation?5number?5within?5this?5f@ 10015cac
MSVCRTD:_error_.obj
0003:00000ce0 ??_C@_08OMAHNMHJ@?6Data?3?5?$DM?$AA@ 10015ce0
MSVCRTD:_error_.obj
0003:00000cec ??_C@_09FOPFMPEJ@wsprintfA?$AA@ 10015cec
MSVCRTD:_error_.obj
0003:00000cf8 ??_C@_0L@GMPLCCII@user32?4dll?$AA@ 10015cf8
MSVCRTD:_error_.obj
0003:00000d08 ??_C@_05MKKEDADM@?$CF?42X?5?$AA@ 10015d08
MSVCRTD:_error_.obj
0003:00000d10
??_C@_0DE@OHJBPMBP@A?5variable?5is?5being?5used?5without@ 10015d10
MSVCRTD:_error_.obj
0003:00000d50 ??_C@_0M@EKFFODEC@MSPDB80?4DLL?$AA@ 10015d50
MSVCRTD:_pdblkup_.obj
0003:00000d60 ??_C@_01KDCPPGHE@r?$AA@ 10015d60
MSVCRTD:_pdblkup_.obj
0003:00000d64 ??_C@_0BB@KCIACLNC@PDBOpenValidate5?$AA@ 10015d64
MSVCRTD:_pdblkup_.obj
0003:00000d78 ??_C@_0BF@BMIHBHCA@EnvironmentDirectory?$AA@ 10015d78
MSVCRTD:_pdblkup_.obj
0003:00000d94 ??_C@_0CN@JNNIHDGH@SOFTWARE?2Microsoft?2VisualStudio?2@
10015d94 MSVCRTD:_pdblkup_.obj
0003:00000dcc ??_C@_0M@HLOHPNFA@RegCloseKey?$AA@ 10015dcc
MSVCRTD:_pdblkup_.obj
0003:00000ddc ??_C@_0BB@HHEIPGME@RegQueryValueExA?$AA@ 10015ddc
MSVCRTD:_pdblkup_.obj
0003:00000df0 ??_C@_0O@DCOGKJGG@RegOpenKeyExA?$AA@ 10015df0
MSVCRTD:_pdblkup_.obj
0003:00000e00 ??_C@_0N@JJPEKNFO@ADVAPI32?4DLL?$AA@ 10015e00
MSVCRTD:_pdblkup_.obj
0003:000010ac ___rtc_iaa 100160ac
MSVCRTD:_initsect_.obj
0003:000012b4 ___rtc_izz 100162b4
MSVCRTD:_initsect_.obj
0003:000013b8 ___rtc_taa 100163b8
MSVCRTD:_initsect_.obj
0003:000015c0 ___rtc_tzz 100165c0
MSVCRTD:_initsect_.obj
0004:00000000 ___native_dllmain_reason 10017000
MSVCRTD:natstart.obj
0004:00000004 ___native_vcclrit_reason 10017004
MSVCRTD:natstart.obj
0004:0000000c ___security_cookie 1001700c
MSVCRTD:gs_cookie.obj
0004:00000010 ___security_cookie_complement 10017010
MSVCRTD:gs_cookie.obj
0004:00000014 ?_RTC_ErrorLevels@@3PAHA 10017014
MSVCRTD:_error_.obj
0004:0000014c __forceCRTManifestRTM 1001714c
MSVCRTD:crtmanifestrtm.obj
0004:00000150 ?__type_info_root_node@@3U__type_info_node@@A 10017150
MSVCRTD:tncleanup.obj
0004:0000015c ?wsprintffp@@3P6AHPADPBDZZA 1001715c
MSVCRTD:_error_.obj
0004:00000534 __adjust_fdiv 10017534 <common>
0004:00000540 ___native_startup_state 10017540 <common>
0004:00000550 ___native_startup_lock 10017550 <common>
0004:00000554 ___onexitend 10017554 <common>
0004:00000564 ___onexitbegin 10017564 <common>
0004:00000568 ___dyn_tls_init_callback 10017568 <common>
0005:00000000 __IMPORT_DESCRIPTOR_MSVCR90D 10018000
MSVCRTD:MSVCR90D.dll
0005:00000014 __IMPORT_DESCRIPTOR_KERNEL32 10018014
kernel32:KERNEL32.dll
0005:00000028 __NULL_IMPORT_DESCRIPTOR 10018028
MSVCRTD:MSVCR90D.dll
0005:0000016c __imp__GetTickCount@0 1001816c
kernel32:KERNEL32.dll
0005:00000170 __imp__SetUnhandledExceptionFilter@4 10018170
kernel32:KERNEL32.dll
0005:00000174 __imp__UnhandledExceptionFilter@4 10018174
kernel32:KERNEL32.dll
0005:00000178 __imp__GetCurrentProcess@0 10018178
kernel32:KERNEL32.dll
0005:0000017c __imp__TerminateProcess@8 1001817c
kernel32:KERNEL32.dll
0005:00000180 __imp__FreeLibrary@4 10018180
kernel32:KERNEL32.dll
0005:00000184 __imp__VirtualQuery@12 10018184
kernel32:KERNEL32.dll
0005:00000188 __imp__GetModuleFileNameW@12 10018188
kernel32:KERNEL32.dll
0005:0000018c __imp__GetProcessHeap@0 1001818c
kernel32:KERNEL32.dll
0005:00000190 __imp__HeapAlloc@12 10018190
kernel32:KERNEL32.dll
0005:00000194 __imp__HeapFree@12 10018194
kernel32:KERNEL32.dll
0005:00000198 __imp__LoadLibraryA@4 10018198
kernel32:KERNEL32.dll
0005:0000019c __imp__GetProcAddress@8 1001819c
kernel32:KERNEL32.dll
0005:000001a0 __imp__lstrlenA@4 100181a0
kernel32:KERNEL32.dll
0005:000001a4 __imp__MultiByteToWideChar@24 100181a4
kernel32:KERNEL32.dll
0005:000001a8 __imp__WideCharToMultiByte@32 100181a8
kernel32:KERNEL32.dll
0005:000001ac __imp__DebugBreak@0 100181ac
kernel32:KERNEL32.dll
0005:000001b0 __imp__RaiseException@16 100181b0
kernel32:KERNEL32.dll
0005:000001b4 __imp__IsDebuggerPresent@0 100181b4
kernel32:KERNEL32.dll
0005:000001b8 __imp__DisableThreadLibraryCalls@4 100181b8
kernel32:KERNEL32.dll
0005:000001bc __imp__InterlockedExchange@8 100181bc
kernel32:KERNEL32.dll
0005:000001c0 __imp__Sleep@4 100181c0
kernel32:KERNEL32.dll
0005:000001c4 __imp__InterlockedCompareExchange@12 100181c4
kernel32:KERNEL32.dll
0005:000001c8 __imp__QueryPerformanceCounter@4 100181c8
kernel32:KERNEL32.dll
0005:000001cc __imp__GetCurrentThreadId@0 100181cc
kernel32:KERNEL32.dll
0005:000001d0 __imp__GetCurrentProcessId@0 100181d0
kernel32:KERNEL32.dll
0005:000001d4 __imp__GetSystemTimeAsFileTime@4 100181d4
kernel32:KERNEL32.dll
0005:000001d8 \177KERNEL32_NULL_THUNK_DATA 100181d8
kernel32:KERNEL32.dll
0005:00000218 __imp___crt_debugger_hook 10018218
MSVCRTD:MSVCR90D.dll
0005:0000021c __imp___except_handler4_common 1001821c
MSVCRTD:MSVCR90D.dll
0005:00000220 __imp___onexit 10018220
MSVCRTD:MSVCR90D.dll
0005:00000224 __imp___lock 10018224
MSVCRTD:MSVCR90D.dll
0005:00000228 __imp____dllonexit 10018228
MSVCRTD:MSVCR90D.dll
0005:0000022c __imp___unlock 1001822c
MSVCRTD:MSVCR90D.dll
0005:00000230 __imp____clean_type_info_names_internal 10018230
MSVCRTD:MSVCR90D.dll
0005:00000234 __imp____CppXcptFilter 10018234
MSVCRTD:MSVCR90D.dll
0005:00000238 __imp___adjust_fdiv 10018238
MSVCRTD:MSVCR90D.dll
0005:0000023c __imp___amsg_exit 1001823c
MSVCRTD:MSVCR90D.dll
0005:00000240 __imp___initterm_e 10018240
MSVCRTD:MSVCR90D.dll
0005:00000244 __imp___initterm 10018244
MSVCRTD:MSVCR90D.dll
0005:00000248 __imp___CrtSetCheckCount 10018248
MSVCRTD:MSVCR90D.dll
0005:0000024c __imp___decode_pointer 1001824c
MSVCRTD:MSVCR90D.dll
0005:00000250 __imp___encoded_null 10018250
MSVCRTD:MSVCR90D.dll
0005:00000254 __imp___free_dbg 10018254
MSVCRTD:MSVCR90D.dll
0005:00000258 __imp___malloc_dbg 10018258
MSVCRTD:MSVCR90D.dll
0005:0000025c __imp___encode_pointer 1001825c
MSVCRTD:MSVCR90D.dll
0005:00000260 __imp___CRT_RTC_INITW 10018260
MSVCRTD:MSVCR90D.dll
0005:00000264 \177MSVCR90D_NULL_THUNK_DATA 10018264
MSVCRTD:MSVCR90D.dll

entry point at 0002:000000d7

--------------------


regards,
George

Norbert Unterberg

unread,
Oct 8, 2008, 10:24:58 AM10/8/08
to
George schrieb:

> Thanks Norbert,
>
>
> Here is the content of the source file of the dll, maindll.cpp and my map
> file content, it does not contain information about an export section as you
> mentioned before.
>
> Anything wrong with my environment? I am using VC 2008.

In the Project settings, Configuration Properties, Linker, Debuging
dialog, you need to set both the "Generate Map File" and the "Map
Exports" setting to YES (/MAPINFO:EXPORTS linker option).

Norbert

George

unread,
Oct 9, 2008, 3:14:01 AM10/9/08
to
Thanks Norbert,


1.

I have tried there is only exports section for map file for a DLL, not for
an EXE, correct?

2.

How do you usually use MAP file in your experience? Share some good points?
:-)


regards,
George

Norbert Unterberg

unread,
Oct 9, 2008, 1:13:40 PM10/9/08
to

George schrieb:


> Thanks Norbert,
>
>
> 1.
>
> I have tried there is only exports section for map file for a DLL, not for
> an EXE, correct?

EXE files actually can export data, as far as I know. But you only have an
export section when you export something. Did you export something in your EXE file?

> 2.
>
> How do you usually use MAP file in your experience? Share some good points?
> :-)

No, I don't. When I have linking problems I sometimes try to find the cause in
the MAP file, but usually the most important information is missing.

Norbert

George

unread,
Oct 10, 2008, 5:26:00 AM10/10/08
to
Thanks Norbert,


1.

I am interested in how you usually use MAP file? To find internal symbols
and exported symbols are the two major function I could think of. Do you have
any other usage for MAP file?

2.

But I am not sure how you use the internal symbol data actually. Could you
show some typical usage scenarios? :-)

3.

I agree with you export in EXE is not usual. We should normally not do that.


regards,
George

Norbert Unterberg

unread,
Oct 18, 2008, 7:22:41 AM10/18/08
to
Gorge,

1. No, usually I don't use them.

2. I usually do not use it, so I can' show any.

3. That's what I think, too.

Norbert

George

unread,
Oct 21, 2008, 7:32:08 AM10/21/08
to
Thanks for your clarification, Norbert!


regards,
George

0 new messages