- User Since
- Jul 25 2016, 12:54 PM (56 w, 1 d)
Mon, Aug 21
Sat, Aug 19
After digging in further, I found an even more elegant way of fixing it. And when expanding that fix to isVUZPMask and isVTRNMask, I noticed that the exact same fix as I was trying to provide already was present in isVTRNMask. So expanding that fix to all of them now, with the same code formatting style as in the existing check.
Fri, Aug 18
Understood the root cause better, with the hidden assumptions of isVZIPMask where both outputs are used.
Thu, Aug 17
Ping @martell - do you have time to update this patch according to Rui's review?
Wed, Aug 16
@hans - I guess this should be backport-worthy as well?
Tue, Aug 15
Just FWIW, I was about to commit this, but noticed that this test actually depends on D36545, which depends on D36544 (which is yet unapproved). So I'll need to hold off of this one until those patches are merged first.
Mon, Aug 14
Sun, Aug 13
Sat, Aug 12
@compnerd - are you ok with this one as well?
Updated to set the right name type for C++ symbols as well, including a testcase for it.
Fri, Aug 11
Thanks for the review! Updated with the changes that Rui requested.
Renamed AArch64MCAsmInfoMicrosoft to AArch64MCAsmInfoMicrosoftCOFF.
Thu, Aug 10
Instead of this patch, we could also update`getNameType` to check for decoration, e.g like this:
if (!Sym.startswith("?") && Sym.find('@', 1) != Sym.npos) return IMPORT_NAME_UNDECORATE;
Fixed aliases with stdcall, added a test for that.
Ping @compnerd, any further comments on this?
Once done, this should hopefully also go into 5.0, since without it, llvm-dlltool doesn't work for mingw-w64 for i386. It's not a regression but a tool that is new for 5.0.
Forgot to say explicitly, that this depends on D36544. This also fixes a regression since 4.0, where linking to import libraries with stdcall creates broken executables. So once done, this and D36544 should be backported to 5.0, ping @hans.
Changed the undecorate action into something that should work for all of cdecl/stdcall/fastcall/vectorcall. Vectorcall doesn't work here yet since the def parser always prepends an underscore though (and fixing that is a separate topic that involves quite a bit of lld as well), but at least this particular line should be mostly fine now.
@martell - to further show the point I'm trying to explain, have a look at the testcase I'm adding in this patch - it shows exactly what should happen. A def file with a decorated name produces an import library with the symbols still decorated, but with the undecorate name type.
Wed, Aug 9
Tue, Aug 8
Rui, do you want to look more on this and the related references, or shall I go ahead and commit it?
Mon, Aug 7
Ping @mgrang, can you check the above with MSVC? I'd like to move forward with this in one form or another.
Sun, Aug 6
Added a fixme comment about this being incorrect for WinCE.
Made the GNU case the default. Apparently I didn't have to update the existing test either, because aarch64-windows still triggers isWindowsMSVCEnvironment (but not isKnownWindowsMSVCEnvironment).
I think one important question that needs to be looked into is, does GNU ld align comm symbols at all if we omit this? There's a neat testcase in lld (COFF/common-something iirc) that you might use as base for figuring that out. If it doesn't, I'm afraid we can't do this.
Updated to use a switch, added a mapping of a missed case of thumb while reformatting the if to a switch.
Limited the change to GNU environments.
Sat, Aug 5
An example of where this is used is e.g. https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/stdio/scanf2-template.S (with aarch64 support is added in a patch at https://sourceforge.net/p/mingw-w64/mailman/message/35983275/).