MKL的各类子程序重定位问题
本帖最后由 山大克鲁士 于 2014-6-30 15:13 编辑问题描述：在调用MKL的时候，直接拉dll、lib和h，但在实际调用的时候发现，h中声明的函数和dll出口的子程序名字完全对不上。
相关资料：mkl_blas.h、mkl_intel_c_dll.lib、mkl_core.dll
In mkl_blas.h：void DGEMM(const char *transa, const char *transb, const MKL_INT *m, const MKL_INT *n, const MKL_INT *k,
const double *alpha, const double *a, const MKL_INT *lda, const double *b, const MKL_INT *ldb,
const double *beta, double *c, const MKL_INT *ldc);
Dumpbin /exports from mkl_core.dll：ordinal hint RVA name
383 17E 0085F1E0 mkl_blas_dgemm
Dumpbin /all from mkl_intel_c_dll.lib：Archive member name at D5992: _dgemm.obj/
5256C8FB time/date Thu Oct 10 23:34:19 2013
uid
gid
100666 mode
312 size
correct header end
FILE HEADER VALUES
14C machine (i386)
2 number of sections
5256C8FB time date stamp Thu Oct 10 23:34:19 2013
1E2 file pointer to symbol table
C number of symbols
0 size of optional header
0 characteristics
SECTION HEADER #1
.drectve name
0 physical address
0 virtual address
2E size of raw data
64 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
100A00 flags
Info
Remove
1 byte align
RAW DATA #1
00000000: 2D 64 65 66 61 75 6C 74 6C 69 62 3A 22 75 75 69-defaultlib:"uui
00000010: 64 2E 6C 69 62 22 20 2D 64 65 66 61 75 6C 74 6Cd.lib" -defaultl
00000020: 69 62 3A 22 75 75 69 64 2E 6C 69 62 22 20 ib:"uuid.lib"
Linker Directives
-----------------
-defaultlib:"uuid.lib"
-defaultlib:"uuid.lib"
SECTION HEADER #2
.text name
0 physical address
0 virtual address
114 size of raw data
92 file pointer to raw data
1A6 file pointer to relocation table
0 file pointer to line numbers
6 number of relocations
0 number of line numbers
60300020 flags
Code
4 byte align
Execute Read
RAW DATA #2
00000000: 55 8B EC 83 EC 08 C7 04 24 00 00 00 00 E8 00 00U.......$.......
00000010: 00 00 83 C4 04 83 C4 C4 8B 45 08 89 04 24 8B 45.........E...$.E
00000020: 0C 89 44 24 04 8B 45 10 89 44 24 08 8B 45 14 89..D$..E..D$..E..
00000030: 44 24 0C 8B 45 18 89 44 24 10 8B 45 1C 89 44 24D$..E..D$..E..D$
00000040: 14 8B 45 20 89 44 24 18 8B 45 24 89 44 24 1C 8B..E .D$..E$.D$..
00000050: 45 28 89 44 24 20 8B 45 2C 89 44 24 24 8B 45 30E(.D$ .E,.D$$.E0
00000060: 89 44 24 28 8B 45 34 89 44 24 2C 8B 45 38 89 44.D$(.E4.D$,.E8.D
00000070: 24 30 8B 45 3C 89 44 24 34 8B 45 40 89 44 24 38$0.E<.D$4.E@.D$8
00000080: E8 00 00 00 00 89 45 FC 83 C4 3C 8B 45 FC 85 C0......E...<.E...
00000090: 75 73 83 C4 C4 8B 45 08 89 04 24 8B 45 0C 89 44us....E...$.E..D
000000A0: 24 04 8B 45 10 89 44 24 08 8B 45 14 89 44 24 0C$..E..D$..E..D$.
000000B0: 8B 45 18 89 44 24 10 8B 45 1C 89 44 24 14 8B 45.E..D$..E..D$..E
000000C0: 20 89 44 24 18 8B 45 24 89 44 24 1C 8B 45 28 89 .D$..E$.D$..E(.
000000D0: 44 24 20 8B 45 2C 89 44 24 24 8B 45 30 89 44 24D$ .E,.D$$.E0.D$
000000E0: 28 8B 45 34 89 44 24 2C 8B 45 38 89 44 24 30 8B(.E4.D$,.E8.D$0.
000000F0: 45 3C 89 44 24 34 8B 45 40 89 44 24 38 E8 00 00E<.D$4.E@.D$8...
00000100: 00 00 83 C4 3C C9 C3 90 E9 00 00 00 00 90 E9 00....<...........
00000110: 00 00 00 90 ....
RELOCATIONS #2
Symbol Symbol
Offset Type Applied To Index Name
-------------------------------------------------------
00000009DIR32 00000000 8_cdecl_xerbla
0000000EREL32 00000000 9_mkl_serv_set_xerbla_interface
00000081REL32 00000000 A_mkl_blas_errchk_dgemm
000000FEREL32 00000000 B_mkl_blas_dgemm
00000109REL32 00000000 3.text
0000010FREL32 00000000 3.text
COFF SYMBOL TABLE
000 00000001 ABS notype Static | @feat.00
001 00000000 SECT1notype Static | .drectve
Section length 2E, #relocs 0, #linenums 0, checksum 0
003 00000000 SECT2notype Static | .text
Section length114, #relocs 6, #linenums 0, checksum 0
005 00000000 SECT2notype () External | _dgemm
006 00000108 SECT2notype () External | _dgemm_
007 0000010E SECT2notype () External | _DGEMM
008 00000000 UNDEFnotype () External | _cdecl_xerbla
009 00000000 UNDEFnotype () External | _mkl_serv_set_xerbla_interface
00A 00000000 UNDEFnotype () External | _mkl_blas_errchk_dgemm
00B 00000000 UNDEFnotype () External | _mkl_blas_dgemm
String Table Size = 0x58 bytes
分析讨论：动态库的出口子程序mkl_blas_dgemm，和头文件中声明的函数DGEMM是怎么个对应上的？
一个函数在源代码里可以叫一个名字，在目标代码里可以叫另一个名字，在DLL导出时又可以叫一个名字。不需要一致。 本帖最后由 山大克鲁士 于 2014-6-30 15:58 编辑
为啥链接器不会报错呢？例如：unresolved external symbol _DGEMM难道链接器不是根据函数名+参数列表，来确定该函数在dll中的真实地址？
为什么函数名字可以不一样那？ 山大克鲁士 发表于 2014-6-30 15:55
为啥链接器不会报错呢？例如：unresolved external symbol _DGEMM难道链接器不是根据函数名+参数列表，来确 ...
不是。
显示链接DLL，链接过程并不寻找dll中的真实地址。这个过程在exe加载时完成。
也就是说，exe加载运行时，才去寻找dll的真实地址。
链接时，由导入库（一般为lib）来确定函数名，参数列表。并将dll的名字，dll中的函数名写入exe里，以便运行时查找。
导入库，负责把函数名由符号，转变为dll的寻找线索（dll名和函数导出名），然后在运行时根据线索得到dll的真实地址。 mangix2010 发表于 2014-6-30 16:11
为什么函数名字可以不一样那？
这主要是出于多函数库使用时，避免名称冲突。
比如，某个函数库里有 OpenFile，另一个函数库里也有这个同名函数。同时，编译器提供的运行时库里可能也有。
怎么办？链接时很容易发生重名的情况。
所以，不同的函数库，运行时库，会在函数名的前面后面增加一些前后缀，甚至对函数名进行某些变换。这样减少重名的可能性。
由于这些前后缀或变换是因编译器或函数库而不同的，所以，没有必要让程序员了解具体的细节。因此，这个函数名的转换过程也由编译器自动完成，而无需干涉。
程序员只要做好函数库的设置，或调用协定就可以了。 chuxf 发表于 2014-6-30 16:50
这主要是出于多函数库使用时，避免名称冲突。
比如，某个函数库里有 OpenFile，另一个函数库里也有这个 ...
现在的问题是，他dll的出口函数中只有mkl_blas_dgemm，但是头文件中确是DGEMM，而且没有出现任何与函数名变更相关的宏，比如#define DGEMM mkl_blas_dgemm，但链接器竟然不会报错，神奇了。。。 山大克鲁士 发表于 2014-7-1 13:32
现在的问题是，他dll的出口函数中只有mkl_blas_dgemm，但是头文件中确是DGEMM，而且没有出现任何与函数名 ...
因为有导入库啊。lib里有代码表明 DGEMM 对应什么DLL的导出函数。 chuxf 发表于 2014-7-1 14:22
因为有导入库啊。lib里有代码表明 DGEMM 对应什么DLL的导出函数。
导入库我dumpbin在帖子的图里面了，大神能指点下是哪一段吗？ 山大克鲁士 发表于 2014-7-2 22:42
导入库我dumpbin在帖子的图里面了，大神能指点下是哪一段吗？
对 lib 文件的 COFF 格式没有太多了解，也没你那么爱刨根问底。
可以肯定的是，dumpbin 会输出所有的符号名称（即供给链接程序的名称）。
我不肯定的是，dumpbin 是否会输出在 DLL 里的导入函数名称。
页:
[1]