delorie.com/archives/browse.cgi | search |
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:date:from:to:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; q=dns; s= | |
default; b=tgzh3VJVyJGOqoxoKxhBQajHOGnq+oyd9ah5JQe50O799cPeDpjg4 | |
ribaRlZDG/9snq4AfZ7qMNE+qQdwB7rTZbGPz4T2S81RoUSlfFaD5zb1HoNg3uz/ | |
j2h1NlfhFw4STRZcC6zf/TImkH2dxEHc90JiyQnafbWKHtO/vXPu9Y= | |
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:date:from:to:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; s=default; | |
bh=w5lsH5HPy/KvadYFRY/kEKoIOGo=; b=yyS0KaTbJiUAKvraDh8z+806M9t2 | |
FWWDuWyC6sw12kqGKXVlEdIXuVglKFr7yJ/7geUQW0baJuAZ3bInB48kTMx+BVxT | |
oGodpD/q/4V06Kj3dR0Ch/qLJZcllB62Us/lRhOKAfL3r9oU3fYwrNcG4LWU8fJo | |
b7G1uaSIGCOhtIg= | |
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 |
X-HELO: | calimero.vinschen.de |
Date: | Mon, 7 Apr 2014 11:39:32 +0200 |
From: | Corinna Vinschen <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries |
Message-ID: | <20140407093932.GG2061@calimero.vinschen.de> |
Reply-To: | cygwin AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
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> |
MIME-Version: | 1.0 |
In-Reply-To: | <lhtqa1$ie3$1@ger.gmane.org> |
User-Agent: | Mutt/1.5.21 (2010-09-15) |
--5UGlQXeG3ziZS81+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 7 09:14, Jean-Pierre Flori wrote: > Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a =C3=A9crit=C2=A0: > > 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:=20= =20 > >> 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:=20= =20 > >> e8 f7 71 00 00 callq 100408310 > >> <__imp___gmpn_store> > >=20 > > 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. > >=20 > > The problem at this point is that I can't reproduce your issue with a > > simple example. Here's the example: > >=20 > > =3D=3D=3D=3D SNIP =3D=3D=3D=3D > > $ cat > lib.c <<EOF #include <stdio.h> > >=20 > > int foo (int a) > > { > > printf ("a =3D %d\n", a); > > return a; > > } > > EOF $ cat > app.c <<EOF #include <stdio.h> > >=20 > > extern int foo (int); > >=20 > > int main () > > { > > int x =3D foo (42); printf ("x =3D %d\n", x); > > return 0; > > } > > EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $ > > ./app a =3D 42 x =3D 42 =3D=3D=3D=3D SNAP =3D=3D=3D=3D > >=20 > > Let's have a look into the executable: > >=20 > > $ objdump -d app.exe [...] > > 00000001004010d0 <main>: > > 1004010d0: 55 push %rbp 1004010d1: 48 89 > > e5 mov %rsp,%rbp 1004010d4: 48 83 ec 30=20=20=20= =20=20=20=20=20=20=20 > > sub $0x30,%rsp 1004010d8: e8 93 00 00 00 callq=20 > > 100401170 <__main> > > 1004010dd: b9 2a 00 00 00 mov $0x2a,%ecx 1004010e2:=20= =20 > > e8 59 06 00 00 callq 100401740 <foo> > > 1004010e7: 89 45 fc mov %eax,-0x4(%rbp) > > [...] > >=20 > > So the call to foo is a call to address 1:00401740. Let's have a look > > what is at that address: > >=20 > > 0000000100401740 <foo>: > > 100401740: ff 25 1a 5a 00 00 jmpq *0x5a1a(%rip) # > > 100407160 <__imp_foo> > >=20 > > Address 100407160 is somewhere within the IAT which gets relocated at > > runtime. > For most functions I indeed see this trampoline trick within the binary. > >=20 > > This is exactly as it's supposed to be. > >=20 > > 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=20 > 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? So IIUC, the assembler code in mpn_store contains a fixed callq, like this: callq foo And this crashes when foo is in an external DLL. This is no wonder at all. x86_64 does not have a callq opcode with 64 bit absolute addressing. What you get in the example above is 32 bit PC-relative addressing, so if foo is not part of the same binary, you're likely to crash because the offset is just wrong. AFAICS, what you have to do is to change your asse4mbler code to create your own jump trampoline, or any other method which evaluates the=20 correct 64 bit address in a place which is accessible via callq: movq __imp_foo, %rax callq *%rax [...] __imp_foo: .quad foo or callq __jmp_foo [...] __jmp_foo jmp foo HTH, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --5UGlQXeG3ziZS81+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTQnJUAAoJEPU2Bp2uRE+gMPMP/A133PzllK1CtQQzTddY6y6P ANlrRPO4U4BoeGd8a7R7hw4e4cgqgWv4/f5QS/3QC0rgBdZyE/c+bF19kEbneRyn 7U7ppZvW06KbT3B8fqpA9iCzoJ/yq/a5jJXJb9ynxi4/0UZfkYEP8ujNXyv2hI8f C7lFfIA3R/fkgu7QVY8uFbVzrjzSn7ZM5RNCiBrMcToSmj8Xigp6ZUbQLqTJFrSM r2yCSenb6eu31fpP2EkyoD2B/tNl1woWLMVO2Ob7so+sLF7MVbwMS30hg9U8dLwe 2GhLLaH5XGRqnW5aCrIuHRROWVHQju5Dstl3qdRWWuYaTbDfFWbKDXI/Q1hlsCrs ex1ftXGHx2rFyWb8wldygpFd6u6hQGLiDdudFJYXbarbqgmoIuRzIQBTIT2wCDvH gZEUeKkBM17kOdhAjzTf0H82nXletz5A/8qmSDCUOalv5NHyipJMSSEZIkDG4cr2 tVxp4A7jJjKMOwscRe6X2BOjUknEtIJWbW6oRBqbkpqds8Z7DhWEXOFQQKPTDvVa Wdq4DkDnoj286BhQm9YwcvAtPrHxrkHRrGm75aPOWPCThKvj20XdN4fBsRqI6w5Z JMQ5+qHvhBOmR/chXtqeqOUvzhILZlSmxW39NxTMs4K6zTwUnyywU+u8fFELum8p wcPGkuoWdBJ4vfW+uvZu =WF2j -----END PGP SIGNATURE----- --5UGlQXeG3ziZS81+--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |