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=MhJAlWwy1X542E/WcK0WWteLz/XoNpfOb/yuE0l6rrUD7o1A8XTyW
	r39Neg2/6w8mPh4ywlKT6NBbkhoXQ98iUGIGSTg4t+xGN6wOnhtqrdzW1+/9XLMT
	rqXxm7kHNjXwWHw5JW11nJ1buGgHIvAdewQRx7CW9AJ0vbhWfUzU/Y=
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=jjMNIU91U+oY2Ktba5Y2AaTYgJQ=; b=NPqc5HQezIOtY+XMN9Z1C4TcOI12
	7uGHTnfzhQx3XmwufGx8bdteEEcEvWemmOQ2THPbN6s6hwEEVnvckXmHoCCJ8RR5
	PfUllj9dmJd849s4z/mgQNQUaSV625svaLpEwZ1351xvFKugCk7RDcO+ZtmAzwJc
	AXtEIj+laF9cN6g=
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:51:38 +0000 (UTC)
Lines:	87
Message-ID:	<lhtsfa$ie3$3@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> <lhtqa1$ie3$1 AT ger DOT gmane DOT org> <20140407093932 DOT GG2061 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 11:39:32 +0200, Corinna Vinschen a écrit :

> On Apr  7 09:14, Jean-Pierre Flori wrote:
>> Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
>> > On Apr  6 20:20, Jean-Pierre Flori wrote:
>> >> 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.
> 
> Just for clarity:  mpn_store is an assembler function calling an
> external C function, right?
> 
Nope, mpn_store is an assembler function indeed, but it's the call to 
this function which fails (which a callq which indeed seems to call it 
from the external library but that code was generated by gcc).


--
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 -