[PATCH] D66996: [llvm-dlltool] Handle external and internal names with differing decoration

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo created this revision.
mstorsjo added reviewers: ruiu, rnk, jacek.
Herald added subscribers: dexonsmith, steven_wu, inglorion, mehdi_amini.
Herald added a project: LLVM.

Also add a missed part of the test from SVN r369747.

I tried looking at GNU ld/dlltool's behaviour wrt decoration, with and without the --kill-at option, and it turned out that lld mostly matched GNU ld's behaviour already (including the surprising case where GNU ld's --kill-at also removes the decoration from the import lib symbol, contrary to what GNU dlltool does). So the main mismatch was in how llvm-dlltool handled these case, and I chose the easy way out; just ignore all variants of "ExtName = Name" and make it behave as if only "ExtName" was specified, which is the only aspect that matters when generating an import library.

@jacek I saw that the patch already landed in wine for stopping including the alias part in the generated def files, but with that reverted, would it work with llvm-dlltool with this patch?


Repository:
  rL LLVM

https://reviews.llvm.org/D66996

Files:
  lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
  test/tools/llvm-dlltool/coff-decorated.def


Index: test/tools/llvm-dlltool/coff-decorated.def
===================================================================
--- test/tools/llvm-dlltool/coff-decorated.def
+++ test/tools/llvm-dlltool/coff-decorated.def
@@ -10,6 +10,8 @@
 StdcallAlias at 4==StdcallFunction at 4
 ??_7exception@@6B@
 StdcallExportName at 4=StdcallInternalFunction at 4
+OtherStdcallExportName at 4=CdeclInternalFunction
+CdeclExportName=StdcallInternalFunction at 4
 
 ; CHECK: Name type: noprefix
 ; CHECK: Symbol: __imp__CdeclFunction
@@ -25,5 +27,12 @@
 ; CHECK: Symbol: ??_7exception@@6B@
 ; CHECK-NM: W _StdcallAlias at 4
 ; CHECK-NM: U _StdcallFunction at 4
+; CHECK: Name type: undecorate
 ; CHECK: Symbol: __imp__StdcallExportName at 4{{$}}
 ; CHECK: Symbol: _StdcallExportName at 4{{$}}
+; CHECK: Name type: undecorate
+; CHECK: Symbol: __imp__OtherStdcallExportName at 4{{$}}
+; CHECK: Symbol: _OtherStdcallExportName at 4{{$}}
+; CHECK: Name type: noprefix
+; CHECK: Symbol: __imp__CdeclExportName
+; CHECK: Symbol: _CdeclExportName
Index: lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
===================================================================
--- lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
+++ lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
@@ -147,6 +147,18 @@
     return 1;
   }
 
+  // If ExtName is set (if the "ExtName = Name" syntax was used), overwrite
+  // Name with ExtName and clear ExtName. When only creating an import
+  // library and not linking, the internal name is irrelevant. This avoids
+  // cases where writeImportLibrary tries to transplant decoration from
+  // symbol decoration onto ExtName.
+  for (COFFShortExport& E : Def->Exports) {
+    if (!E.ExtName.empty()) {
+      E.Name = E.ExtName;
+      E.ExtName.clear();
+    }
+  }
+
   if (Machine == IMAGE_FILE_MACHINE_I386 && Args.getLastArg(OPT_k)) {
     for (COFFShortExport& E : Def->Exports) {
       if (!E.AliasTarget.empty() || (!E.Name.empty() && E.Name[0] == '?'))
@@ -161,7 +173,6 @@
       // By making sure E.SymbolName != E.Name for decorated symbols,
       // writeImportLibrary writes these symbols with the type
       // IMPORT_NAME_UNDECORATE.
-      E.ExtName = E.ExtName.substr(0, E.ExtName.find('@', 1));
     }
   }
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D66996.218067.patch
Type: text/x-patch
Size: 2190 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190830/70983ec5/attachment.bin>