[PATCH v2] mscoree: Implement VTable fixup for x86_64 architecture.

[Paul Gofman]

On 01/22/2016 11:45 PM, Vincent Povirk wrote:
>> That's not quite true for __vectorcall convention. From your first link
>> for XMM4,YMM4 for instance:  "Must be preserved as needed by caller;
>> *fifth vector-type argument when __vectorcall is used*". So to support
>> all the possible cases we need to preserve all of them I suppose. That's
>> why I added this mess with AVX detection and 2nd thunk version.
> OK, I missed that.
>
> But I don't think it's possible for a .NET method to use __vectorcall
> as its calling convention. The attribute used to specify it doesn't
> have a value for this:
> https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.unmanagedfunctionpointerattribute.unmanagedfunctionpointerattribute.aspx
>
> It's possible MS will extend this in the future, but it's also
> possible they'll make up entirely new calling conventions. I don't
> think they will, and for now I don't think it's worth the extra
> complexity.
Is it the same for managed C++? If you say __vectorcall support is not
needed I will of course remove this code.

> The only potential problem I see with
> __attribute__((force_align_arg_pointer)) is that we may want to use
> compilers other than GCC (such as clang or msvc), and they may not
> support this attribute. 
If they do not support it they should just issue compiler warning, or am
I missing something? Clang may hopefully add the suport. msvc is very
unlikely to compile Wine soon I guess. Intel Compiler does not support
ms_abi attribute at all and thus compiling wine 64bit with it is totally
not feasible for now.

>
>
> How likely do you think it is that there's code out there that calls a
> .NET method with wrong alignment? Maybe we don't need to worry about
> this.
I can guess it might be just nearly as likely as without .NET. See this
bug: https://bugs.winehq.org/show_bug.cgi?id=27680: there is 7-8 apps
w/o .NET known so far. As I got from brief googling native .Net should
not suffer from stack misalignment. So I thought it won't hurt to add an
attribute to ReallyFixupVTable (which presumably will be universally
supported some day) , but considered too much forcing alignment right in
the thunk.
>
> I only took a quick look and could be wrong, but from looking at
> mono_arch_emit_prolog in mini-amd64.c it seems like Mono also assumes
> an aligned stack on entry to the functions it generates, meaning we'd
> get a crash eventually anyway.
Are you sure they are going to crash? I looked at the code produced by
'mono --aot' on my short class, they are not storing xmm regs routinely
to stack at prolog. Our ms_abi functions do that just because they call
non-msabi functions and this is not the case for mono which has ms-abi
through all the code, they do not need to do that unless the function
modifies non-volatile XMM registers. Even if they do store on stack in
this case, they could do it through unaligned instructions or fix stack
alignment in such function.