Possible issue on windows build (mingw)

[Vlad Gabriel]

Hello Torbjörn,

gcd_1.asm related
I can confirm that replacing
    sub    $8, %rsp
    add    $8, %rsp
with
    sub    $40, %rsp
    add    $40, %rsp
However, I can not understand why. Dwelving into Win64 ABI is not the most friendly stuff. One opinion, is that the caller always has to reserve space on stack to callee to home-registers. That is required by the calling convention. The space is used by the callee to store the 1st four parameters onto stack. It does not matter that the callee has 0 or less than 4 parameters, caller must allocate space on stack for callee to "home" the param registers. However, the callee are your own asm functions, that do not store the parameters on stack, so I am confused as why it works like that.

If you want to make your assembler windoze friendly, you can take a look @ http://msdn.microsoft.com/en-us/library/7kcdt6fy%28v=vs.80%29.aspx. There is the reference for all that matters. I can summarize a few key concepts, but the reference is in the link above.
- The ABI specifies 2 types of functions:
        frame function - call other functions and/or use alloca() and/or allocates stack space and/or saves nonvolatile registers and/or uses exception handling.

        leaf functions - does nothing of the above.
- The ABI specifies how to write a frame function so it can be unwinded (by the OS). This impose great restriction on prologue, epilogue and stack manipulation. It also make heavy use of assembler directives that magically generates the required info to unwind the function. Good thing is that latest GNU binutils do support the directives, bad news is that they are not documented in their help. However, the naming is very similar between GNU binutils and Microsoft Assembler (MASM). You can take a look @

    http://msdn.microsoft.com/en-us/library/ms235231%28v=vs.80%29.aspx
   <GNUBinutils>/gas/config/obj-coff-seh.h

    http://msdn.microsoft.com/en-us/library/ew5tede7%28v=vs.80%29.aspx
- The ABI specifies the call convention.

- The ABI specifies register usage, rax, rcx, rdx, r8, r9, r10, r11 can be clobbered, rbx, rbp, rdi, rsi, r12, r13, r14,  r15 must be preserved.

- The ABI specifies strict 16byte stack allignment.

Regarding mpn/x86_64/coreinhm/gcd_1.asm
You are obviously right, I copied there by mistake while testing each assembler.

Regarding cxx/t-locale.
Well, it gives a false negative. False in the sense that it does not signal an error in GMP itself, but in the test. Error is caused by the linker giving a "duplicate symbol" message and bailing out, thus failing the test.
If you correct the duplicate symbol, the link will succeed, but then the test will give a false positive, because it relies on the ability to "overwrite" a libc funtion (localeconv()/nl_langinfo()) which is not possible on windows with a dll libc.
That being said, it is for you to decide whether or not it is worth fixing it.

Thanks for your support,
Gabriel


________________________________
 From: Torbjorn Granlund <tg at gmplib.org>
To: Vlad Gabriel <clampi at yahoo.com> 
Cc: gmp-bugs at gmplib.org 
Sent: Tuesday, April 3, 2012 4:28 PM
Subject: Re: Possible issue on windows build (mingw)
 
Vlad Gabriel <clampi at yahoo.com> writes:

  I confirm that the assert issue (toom_eval_pm2exp.c:112) was solved by patch 2.
  
Thanks!

  The issue with t-gcd and t-get_d is reproducible. I have to have present either of
  mpn/x86_64/coreinhm/gcd_1.asm
  
  mpn/x86_64/core2/gcd_1.asm
  mpn/x86_64/gcd_1.asm

I am stuck here, since I see nothing wrong with the code, nor am I able
to reproduce the gcd_1 problems on my machine.  This could be a compiler
problem (you're using a prerelease, I think) or a GMP--windoze
compatibility problem.

Can you see someting wrong with (say) core2/gcd_1.asm?

Perhaps you could even run a debugger session over the file, comparing
it to a valid run with the same arguments (on a GNU/Linux or BSD
system)?

There are two things to be suspicious about: (1) the entry/exit sequence
(see the DOS64_ENTRY and DOS64_EXIT macros, and (2) the calls to
mpn_mod_1 and mpn_modexact_1_odd.

Does the code work if you change all

    sub    $8, %rsp
and
    add    $8, %rsp

instructions in the used gcd_1.asm to

    sub    $40, %rsp
and
    add    $40, %rsp

respectively?  (The C version of this file, when compiled to assembly
has such seemingly useless stack allocation.  I'll check the windoze ABI
docs to understand this better, before releasing this code.)

  For reference, 'mpn/x86_64/coreinhm/gcd_1.asm' and
  'mpn/x86_64/core2/gcd_1.asm' are the same file. Even if that would
  have not caused error on my end, I think is not supposed to have the
  same file for 2 processors, but have configure do the link.
  
I don't think there is any file at mpn/x86_64/coreinhm/gcd_1.asm
(neither in the repo nor in any recent snapshot).  There are
"implementation files" in mpn/x86_64/gcd_1.asm and
mpn/x86_64/core2/gcd_1.asm, plus "grabber files" in
mpn/x86_64/nano/gcd_1.asm, mpn/x86_64/bd1/gcd_1.asm, and
mpn/x86_64/k10/gcd_1.asm.
  
  There is something I have not mentioned in any of my previous mails,
  something that was brought up a while ago to your attention but did
  not get any resolution. Test cxx/t-locale is irrelevant for windoze
  targets (PE-COFF). This is due to the test being dependent of the weak
  symbols concept. That is not supported by PE-COFF targets (mingw32/64
  and cygwin as far as I know). In my opinion it should be skipped from
  makefile for those targets, as simply ignoring the test from int
  main(){std::cout<<"Not supported on Windoze"<<endl;} would still cause
  a duplicate symbol at link time in clocale.o.

I am not sure I follow.  Does it cause a real problem?  I prefer to keep
configure complexity down (this my striving might not be obvious from
the current complexity...) and ony address actual problems, not somewhat
hypothetical problems.  (I don't indend to be rude here, please don't
read it as a rude reply!)

-- 
Torbjörn