[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: dlltool delaylibs corrupt float/double arguments

From: Nick Clifton
Subject: Re: Bug: dlltool delaylibs corrupt float/double arguments
Date: Fri, 17 Jun 2022 11:21:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

Hi Strager,

I think the solution is for dll's delaylib trampoline to
save xmm1 on the stack before calling __delayLoadHelper2.
I made a patch which does this, and it fixes the bug for my

Thanks very much for taking the time to track down the cause
of this problem. and for creating a patch. :-)

See attached patch. I think my patch has two problems:

1. AVX/vmovupd/ymm might not be usable on the target
    machine, but saving just xmm isn't enough. Should we
    perform a CPUID check?

This would only work if the dlltool is run on the same machine,
or same type of machine, as the target machine.  Probably a
safer solution would be to add a new command line option to
select the extended trampoline.  Then it is up to the user to
select the correct trampoline type.

To be really paranoid if the new option is not enabled and
dlltool is running on an x86_64 host, then it could run a
CPUID check and if extended registers are available, issue
a warning message to the user, reminding them of the possible

2. We store unaligned with vmovupd. Storing aligned with
    vmovapd would be better. I haven't looked into how to
    align ymm registers when storing on the stack.

"Better" as in better performance, yes ?  I think that in this
case safer is more important than faster, so sticking with
unaligned moves should be OK.

I'd love to get this bug fixed so others don't spend two
days debugging assembly code!

Would you be willing to work on the improvements suggested
above and submitting a revised patch ?  The catch here is
that such a patch would need a copyright assignment from
you before we could accept it.  The links below should provide
more details on this.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]