-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[llvm-dlltool] Remove the i386 underscore prefix from COFFImportFile::ImportName. NFC. #98226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This goes on top of #98225, only the topmost commit is for review here. |
@llvm/pr-subscribers-llvm-binary-utilities Author: Martin Storsjö (mstorsjo) ChangesOn i386, regular C level symbols are given an underscore prefix When specified in a def file like "symbol == dllname", the "dllname" The mechanism where one symbol is redirected to another one in (This mechanism, with weak aliases, only works as long as the For clarity, for potentially handling the import renaming in When creating the aliases, add the prefix as needed. This requires Full diff: https://github.com/llvm/llvm-project/pull/98226.diff 5 Files Affected:
diff --git a/llvm/include/llvm/Object/COFFImportFile.h b/llvm/include/llvm/Object/COFFImportFile.h
index 649fb4930934d..e91d5a9b3198a 100644
--- a/llvm/include/llvm/Object/COFFImportFile.h
+++ b/llvm/include/llvm/Object/COFFImportFile.h
@@ -135,10 +135,11 @@ struct COFFShortExport {
/// linking both ARM64EC and pure ARM64 objects, and the linker will pick only
/// the exports relevant to the target platform. For non-hybrid targets,
/// the NativeExports parameter should not be used.
-Error writeImportLibrary(
- StringRef ImportName, StringRef Path, ArrayRef<COFFShortExport> Exports,
- COFF::MachineTypes Machine, bool MinGW,
- ArrayRef<COFFShortExport> NativeExports = std::nullopt);
+Error writeImportLibrary(StringRef ImportName, StringRef Path,
+ ArrayRef<COFFShortExport> Exports,
+ COFF::MachineTypes Machine, bool MinGW,
+ ArrayRef<COFFShortExport> NativeExports = std::nullopt,
+ bool AddUnderscores = true);
} // namespace object
} // namespace llvm
diff --git a/llvm/lib/Object/COFFImportFile.cpp b/llvm/lib/Object/COFFImportFile.cpp
index fd8aca393e90b..03af4921ddbca 100644
--- a/llvm/lib/Object/COFFImportFile.cpp
+++ b/llvm/lib/Object/COFFImportFile.cpp
@@ -645,7 +645,8 @@ NewArchiveMember ObjectFactory::createWeakExternal(StringRef Sym,
Error writeImportLibrary(StringRef ImportName, StringRef Path,
ArrayRef<COFFShortExport> Exports,
MachineTypes Machine, bool MinGW,
- ArrayRef<COFFShortExport> NativeExports) {
+ ArrayRef<COFFShortExport> NativeExports,
+ bool AddUnderscores) {
MachineTypes NativeMachine = Machine;
if (isArm64EC(Machine)) {
@@ -691,8 +692,15 @@ Error writeImportLibrary(StringRef ImportName, StringRef Path,
}
if (!E.ImportName.empty() && Name != E.ImportName) {
- Members.push_back(OF.createWeakExternal(E.ImportName, Name, false, M));
- Members.push_back(OF.createWeakExternal(E.ImportName, Name, true, M));
+ StringRef Prefix = "";
+ if (Machine == IMAGE_FILE_MACHINE_I386 && AddUnderscores)
+ Prefix = "_";
+
+ if (ImportType == IMPORT_CODE)
+ Members.push_back(OF.createWeakExternal((Prefix + E.ImportName).str(),
+ Name, false, M));
+ Members.push_back(OF.createWeakExternal((Prefix + E.ImportName).str(),
+ Name, true, M));
continue;
}
diff --git a/llvm/lib/Object/COFFModuleDefinition.cpp b/llvm/lib/Object/COFFModuleDefinition.cpp
index 0c0bef1319e44..82c18539658e8 100644
--- a/llvm/lib/Object/COFFModuleDefinition.cpp
+++ b/llvm/lib/Object/COFFModuleDefinition.cpp
@@ -282,8 +282,6 @@ class Parser {
if (Tok.K == EqualEqual) {
read();
E.ImportName = std::string(Tok.Value);
- if (AddUnderscores && !isDecorated(E.ImportName, MingwDef))
- E.ImportName = std::string("_").append(E.ImportName);
continue;
}
// EXPORTAS must be at the end of export definition
diff --git a/llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp b/llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
index 15e4cac08cd4e..012ad246888f9 100644
--- a/llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
+++ b/llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
@@ -243,8 +243,9 @@ int llvm::dlltoolDriverMain(llvm::ArrayRef<const char *> ArgsArr) {
}
std::string Path = std::string(Args.getLastArgValue(OPT_l));
- if (!Path.empty() && writeImportLibrary(OutputFile, Path, Exports, Machine,
- /*MinGW=*/true, NativeExports))
+ if (!Path.empty() &&
+ writeImportLibrary(OutputFile, Path, Exports, Machine,
+ /*MinGW=*/true, NativeExports, AddUnderscores))
return 1;
return 0;
}
diff --git a/llvm/test/tools/llvm-dlltool/coff-weak-exports.def b/llvm/test/tools/llvm-dlltool/coff-weak-exports.def
index dacc5f73530fd..67f0013bf170f 100644
--- a/llvm/test/tools/llvm-dlltool/coff-weak-exports.def
+++ b/llvm/test/tools/llvm-dlltool/coff-weak-exports.def
@@ -6,6 +6,7 @@
LIBRARY test.dll
EXPORTS
TestFunction==AltTestFunction
+TestData DATA == AltTestData
; When creating an import library, the DLL internal function name of
; the implementation of a function isn't visible at all.
ImpLibName = Implementation
@@ -20,6 +21,9 @@ ImpLibName3 = kernel32.Sleep
; CHECK-NEXT: W TestFunction
; CHECK: U __imp_AltTestFunction
; CHECK-NEXT: W __imp_TestFunction
+; CHECK-NOT: W TestData
+; CHECK: U __imp_AltTestData
+; CHECK-NEXT: W __imp_TestData
; CHECK: T ImpLibName
; CHECK-NEXT: T __imp_ImpLibName
; CHECK: U AltTestFunction2
|
…:ImportName. NFC. On i386, regular C level symbols are given an underscore prefix in the symbols on the object file level. However, the exported names from DLLs usually don't have this leading underscore. When specified in a def file like "symbol == dllname", the "dllname" is the name of the exported symbol from the DLL, which will be linked against from an object file symbol named "_symbol" (on i386). The mechanism where one symbol is redirected to another one in an import library is implemented with weak aliases. In that case, we need to have the object file symbol level name for the target of the import, as we make one object file symbol point at another one. Therefore, we added an underscore to the ImportName field. (This mechanism, with weak aliases, only works as long as the target also is exported as is, in that form - this issue is dealt with in a later commit.) For clarity, for potentially handling the import renaming in other ways, store the ImportName field unprefixed, containing the actual name to import from the DLL. When creating the aliases, add the prefix as needed. This requires passing an extra AddUnderscores parameter to the writeImportLibrary function; this is a temporary measure, until alias creation is reworked in a later commit. This doesn't preserve the corner case of checking !isDecorated() before adding the prefix. This corner case isn't tested by any of our existing tests, and only would trigger for fastcall/vectorcall/MS C++ functions - while these kinds of renames primarily are used in mingw-w64-crt import libraries (which primarily handle cdecl and stdcall functions).
07437ec
to
62bf9e0
Compare
…:ImportName. NFC. (#98226) Summary: On i386, regular C level symbols are given an underscore prefix in the symbols on the object file level. However, the exported names from DLLs usually don't have this leading underscore. When specified in a def file like "symbol == dllname", the "dllname" is the name of the exported symbol from the DLL, which will be linked against from an object file symbol named "_symbol" (on i386). The mechanism where one symbol is redirected to another one in an import library is implemented with weak aliases. In that case, we need to have the object file symbol level name for the target of the import, as we make one object file symbol point at another one. Therefore, we added an underscore to the ImportName field. (This mechanism, with weak aliases, only works as long as the target also is exported as is, in that form - this issue is dealt with in a later commit.) For clarity, for potentially handling the import renaming in other ways, store the ImportName field unprefixed, containing the actual name to import from the DLL. When creating the aliases, add the prefix as needed. This requires passing an extra AddUnderscores parameter to the writeImportLibrary function; this is a temporary measure, until alias creation is reworked in a later commit. This doesn't preserve the corner case of checking !isDecorated() before adding the prefix. This corner case isn't tested by any of our existing tests, and only would trigger for fastcall/vectorcall/MS C++ functions - while these kinds of renames primarily are used in mingw-w64-crt import libraries (which primarily handle cdecl and stdcall functions). Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60251649
On i386, regular C level symbols are given an underscore prefix
in the symbols on the object file level. However, the exported
names from DLLs usually don't have this leading underscore.
When specified in a def file like "symbol == dllname", the "dllname"
is the name of the exported symbol from the DLL, which will be
linked against from an object file symbol named "_symbol"
(on i386).
The mechanism where one symbol is redirected to another one in
an import library is implemented with weak aliases. In that case,
we need to have the object file symbol level name for the target
of the import, as we make one object file symbol point at another
one. Therefore, we added an underscore to the ImportName field.
(This mechanism, with weak aliases, only works as long as the
target also is exported as is, in that form - this issue is
dealt with in a later commit.)
For clarity, for potentially handling the import renaming in
other ways, store the ImportName field unprefixed, containing
the actual name to import from the DLL.
When creating the aliases, add the prefix as needed. This requires
passing an extra AddUnderscores parameter to the writeImportLibrary
function; this is a temporary measure, until alias creation is
reworked in a later commit.
This doesn't preserve the corner case of checking !isDecorated()
before adding the prefix. This corner case isn't tested by any
of our existing tests, and only would trigger for
fastcall/vectorcall/MS C++ functions - while these kinds of
renames primarily are used in mingw-w64-crt import libraries
(which primarily handle cdecl and stdcall functions).