[PATCH] D36548: [llvm-dlltool] Fix creating stdcall import libraries for MinGW/i386

[Martell Malone via Phabricator via llvm-commits]

martell added inline comments.


================
Comment at: lib/Object/COFFModuleDefinition.cpp:232
+        E.SymbolName = E.Name;
+        E.Name = E.Name.substr(0, E.Name.find('@'));
+      }
----------------
mstorsjo wrote:
> rnk wrote:
> > mstorsjo wrote:
> > > rnk wrote:
> > > > Surely this doesn't work for fastcall functions, though? They look like @foo at 4
> > > Hmm, indeed, that's true. Haven't seen such, but they are used in mingw so they clearly need to be handled.
> > > 
> > > I think it would work with just using `rfind` instead of `find`, what do you think?
> > > 
> > > Unrelatedly - do you think we should move this whole block into the dlltool driver instead, since it's mingw specific? We could do a pass over the exports after parsing the def, before passing it to the writer.
> > Unfortunately, vectorcall messes `rfind` up, it does foo@@4: https://msdn.microsoft.com/en-us/library/deaxefa7.aspx
> Ah, crap. Mingw-w64 doesn't seem to have any such functions in the def files though. But I'd rather make it handle them correctly at the same time in any case.
> 
> Wouldn't the existing check for `isDecorated` above also prepend an underscore to it (even though there shouldn't be any, according to that ref)?
In general Mingw def files in general breaks the COFF spec too much.
http://cygwin.com/ml/binutils/2004-09/msg00031.html
We should just put it behind the `--kill-at` flag.
I already have a stub for this in Options.td that you can use.


https://reviews.llvm.org/D36548