DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=cQT2NAzdNyHh2bezmyn571HyUAFis0ompVv2CsiTtu8jcmuCW2kIL
	IarlJ/eXyfvNlMQBzkDIzYF9L++waXgQbITuJlh6xluF4ZJlmIp50sXCB3jc3tOD
	ZbH2jWvKf4aUp67d4U2o7hthzBvzvH3ALYKB7PWTmAMgo5J5OAsj4o=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Jean-Pierre Flori <jpflori AT gmail DOT com>
Subject: Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Date: Sun, 6 Apr 2014 20:20:14 +0000 (UTC)
Lines: 144
Message-ID: <lhsctu$56e$1@ger.gmane.org>
References: 	<CAHhGz8_eESbCpCWivD_G9ciFbE4VsZntZyRdOOOtd2PXUSsmgg AT mail DOT gmail DOT com>	<20140402090750 DOT GP2508 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)

Dear all,

Le Wed, 02 Apr 2014 11:07:50 +0200, Corinna Vinschen a écrit :

> On Apr  2 00:07, Jean-Pierre Flori wrote:
>> Dear all,
>> 
>> It's amazing to see how well Cygwin64 is going.
>> Thanks for your hard work.
>> 
>> While preparing the new MPIR release, which will be the first one to
>> support Cygwin4, we encountered problems running MPIR testsuite when
>> MPIR was configured to produce a shared lib.
>> That's with latest cygwin/binutils/gcc/g++ from today.
>> 
>> It seems that a call to the MPN_ZERO macro, which on my setup is at
>> 0x4ff2746c0 in the shared lib but we get the instruction:
>> callq 0xff2746c0
> 
> This looks suspicious.  On x86_64 this kind of instruction is usually
> PC-relative or uses a jump table, because x86_64 uses the small code
> model by default (medium model on Cygwin).
> 
>> within the test binary and that yields a nice segfault.
>> Please see
>> https://groups.google.com/d/msg/mpir-devel/KzsxIWhVx8A/EAUoP4ybWOMJ and
>> the few following post for more details.
>> 
>> For sure, we don't get what's going on here.
>> Would you have any clue?
> 
> Not without a more detailed report.  The aforementioned link does not
> contain pointers to the source, for instance.  Also, a simple testcase
> might be helpful.
> 
> If you suspect a linker bug, you might contemplate to ask on the
> binutils mailing list binutils AT sourceware DOT org which is where ld
> is maintained.
> 
Here come more details as I've taken a little more time to try to 
understand what was happening.

The problem arosed when running the tests for MPIR.
The latest alpha is available at http://mpir.org/
Currently it's 2.7.alpha4: http://mpir.org/mpir-2.7.0-alpha4.tar.bz2

Note that thanks to your kind support, MPIR should now build correctly on 
Cygwin64 (with or without C++ support). 
That's already great!
(And that might help you to take a look at our problem if you feel 
inclined to do it.)

The problem we recently encountered was the following:
in gmp-impl.h, mpn_store (which can be either a macro or a function if 
efficient assembly is available, and so is always a function on x86_64) 
was not marked __declspec(dllexport/dllimport).
(See https://github.com/wbhart/mpir/blob/master/gmp-impl.h#L2419 for the 
current version with the __GMP_DECLSPEC, defined in mpir.h (from gmp-
h.in) where this gets defined as __declspec(dllimport) for the user 
visible header and use outside of MPIR itself)
It seems that because of this lack, the call to mpn_store from a bunch of 
test executables produced the wrong callq instruction.
Once we added the __GMP_DECLSPEC the function got correctly called.

What I don't really get is that from what I've read e.g. here : https://
access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/
html/Using_ld_the_GNU_Linker/win32.html
is that the dllimport/export should not be needed anymore.

So I took a slightly deeper look and played with the definition of 
__GMP_DECLSPEC in gmp-h.in/mpir.h to be empty or __declspec(dllexport/
import).
The library was built with:
./configure --disable-static --enable-shared
make
make check (-> potential segfaults when testing the mpn dir)

As far as dllexport is concerned, we pass --export-all-symbols to ld, and 
as expected, we don't need the dllexport part when building the library 
(we get __imp_ and __nm_ symbols for functions).

But it seems that the --enable-auto-import counterpart (which should be 
ld default) is defeated.
I've had a look at the assembly and objects produced by gcc before linking 
and they indeed look different.
With the dllimport magic, I get in t-neg.s:
        movq    %rax, %rcx
        movq    __imp___gmpn_store(%rip), %rax
        call    *%rax
Without it I get:
        movq    %rax, %rcx
        call    __gmpn_store
Similar differences in the object file (t-neg.o).
Looking at the exes produced (.libs/t-neg.exe) gives with the dllimport 
magic:
   100401115:   48 89 c1                mov    %rax,%rcx
   100401118:   48 8b 05 f1 71 00 00    mov    0x71f1(%rip),%rax        # 
100408310 <__imp___gmpn_store>
   10040111f:   ff d0                   callq  *%rax
Without it:
   100401111:   48 89 c1                mov    %rax,%rcx
   100401114:   e8 f7 71 00 00          callq  100408310 
<__imp___gmpn_store>


I've tested the same modifications on Cygwin32 and not putting in the 
dllimport stuff (or if you prefer, defining __GMP_DECLSPEC to be empty) is 
no problem.
Let's go through the same t-neg file, but use another function as 
mpn_store is a macro on my 32 bit Cygwin.
In assembly with dllimport:
        movl    %eax, (%esp)
        movl    __imp____gmp_randinit_default, %eax
        call    *%eax
without dllimport:
        movl    %eax, (%esp)
        call    ___gmp_randinit_default
In object file:
  23:   89 04 24                mov    %eax,(%esp)
  26:   a1 00 00 00 00          mov    0x0,%eax
  2b:   ff d0                   call   *%eax
vs:
  23:   89 04 24                mov    %eax,(%esp)
  26:   e8 00 00 00 00          call   2b <_main+0x2b>
In exe file:
  4011b3:       89 04 24                mov    %eax,(%esp)
  4011b6:       a1 74 71 40 00          mov    0x407174,%eax
  4011bb:       ff d0                   call   *%eax

vs:
  4011b3:       89 04 24                mov    %eax,(%esp)
  4011b6:       e8 8d 13 00 00          call   402548 
<___gmp_randinit_default>


I'm also trying to get GCC 4.7.3 rebuilt to see if it makes any 
difference with GCC 4.8.2.


Any advice would be welcomed!

Best,
JP


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple