delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2014/04/07/05:39:53

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019