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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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: References: <20140402090750 DOT GP2508 AT calimero DOT vinschen DOT de> <20140407084312 DOT GA2061 AT calimero DOT vinschen DOT de> <20140407093932 DOT GG2061 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) 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 < >> > >> > int foo (int a) >> > { >> > printf ("a = %d\n", a); >> > return a; >> > } >> > EOF $ cat > app.c < >> > >> > 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
: >> > 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 >> > 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 : >> > 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