X-Recipient:	archive-cygwin AT delorie DOT com
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=Y0eobtWsnQ6LVAP2cmlem5tGDUt8tarwIB0gR/7LiiXj0MadTdOGw
	i0gQshqQVed2kGqXpxVZ4NpKYJ5pG+cbbH7LdaKhR7r3mE5Sl4ZhLPbot3JQUjcd
	62B8igZzBR0zOOPnSp2xL65msUU1iFtMXXjh4HY1ioL9VwRwkZ41DM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	bh=lyaZFtrwVN+CXnwoEE5ApiWrcH0=; b=TAkUFnrTQOLC0T441xpYgmFF+lV8
	tNeZ3/DtiLPF7eUhWHcWxyheiDN8AH8t9i2y2m5hXQwQqtSV1csj8J0Y/RgGQW8W
	eH1BF2kTX8xo/JtEElkUgZvmOzfQP9FWvTLZhurhkBl60JGqqIfTkSWiiATRCDz4
	3oOjAUc0dEek9Nk=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	plane.gmane.org
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:	Mon, 7 Apr 2014 09:14:41 +0000 (UTC)
Lines:	132
Message-ID:	<lhtqa1$ie3$1@ger.gmane.org>
References:	<CAHhGz8_eESbCpCWivD_G9ciFbE4VsZntZyRdOOOtd2PXUSsmgg AT mail DOT gmail DOT com> <20140402090750 DOT GP2508 AT calimero DOT vinschen DOT de> <lhsctu$56e$1 AT ger DOT gmane DOT org> <20140407084312 DOT GA2061 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
User-Agent:	Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)
X-IsSubscribed:	yes

Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :

> On Apr  6 20:20, Jean-Pierre Flori wrote:
>> [...]
>> 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.
> 
> And in fact it isn't.
> 
>> 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>
> 
> This is ok.  Look closely at the address after the callq.  It's the
> start address of the executable (0x1:00400000) plus an offset.  If you
> disassemble the executable you will find a jmp statement at this
> address.  This is the trampoline code which is automatically generated
> for external references if they are not marked with dllimport.
> 
> The problem at this point is that I can't reproduce your issue with a
> simple example.  Here's the example:
> 
> ==== SNIP ====
> $ cat > lib.c <<EOF #include <stdio.h>
> 
> int foo (int a)
> {
>   printf ("a = %d\n", a);
>   return a;
> }
> EOF $ cat > app.c <<EOF #include <stdio.h>
> 
> extern int foo (int);
> 
> int main ()
> {
>   int x = foo (42); printf ("x = %d\n", x);
>   return 0;
> }
> EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $
> ./app a = 42 x = 42 ==== SNAP ====
> 
> Let's have a look into the executable:
> 
> $ objdump -d app.exe [...]
> 00000001004010d0 <main>:
>    1004010d0:   55                      push   %rbp 1004010d1:   48 89
>    e5                mov    %rsp,%rbp 1004010d4:   48 83 ec 30          
>      sub    $0x30,%rsp 1004010d8:   e8 93 00 00 00          callq 
>    100401170 <__main>
>    1004010dd:   b9 2a 00 00 00          mov    $0x2a,%ecx 1004010e2:  
>    e8 59 06 00 00          callq  100401740 <foo>
>    1004010e7:   89 45 fc                mov    %eax,-0x4(%rbp)
>    [...]
> 
> So the call to foo is a call to address 1:00401740.  Let's have a look
> what is at that address:
> 
> 0000000100401740 <foo>:
>    100401740:   ff 25 1a 5a 00 00       jmpq   *0x5a1a(%rip)        #
>    100407160 <__imp_foo>
> 
> Address 100407160 is somewhere within the IAT which gets relocated at
> runtime.
For most functions I indeed see this trampoline trick within the binary.
> 
> This is exactly as it's supposed to be.
> 
> Now, here's the question:  Where is your problem different?  What
> exactly makes your code fail?  Can you construct your problem from my
> simple testcase, or can you construct an equally simple testcase which
> fails?
Looking a little further, it seems the problematic functions are those 
directly assembled from assembly code.
That was the case of mpn_store on x86_64.

And when I remove all dllimport, the call to the function mpn_addadd_n 
also gives a segfault when executing t-addadd_n.exe.

Note that the test t-aors.exe does not segfault, and indeed it only uses 
the mpn_add_1 and mpn_sub_1 functions which are not from assembly.

I'll now try to produce a minimal example.


(I've tried GCC 4.7.3 and it gives the same result.)

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

- Raw text -