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=WeBXCo8zRc6Z6Fidkyz9yEuaTJwLvSrDvs5syvyaVun0+nj1LBrEu
	BFmui7GzXrUYV2VSd5q9dVJzkwtZH31Q0PGJtJDoOq10YPcNUND6BFZNsM21uxUX
	IqLNeHDuKjyfAffNtPMjcTcZBgzaEf/SgzkoRNLyd8EIuh5d4b5UF8=
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=/47F3lPqWd9iI8BSGdqmcH2bKEI=; b=Ea2BKeyL++wdyHpwnbY3Lnjfc6hy
	dqfMTue1yi9JSBKZLI+Mp9RcTwkoM4mMPDZNy0/p2lTrT+U0drS2EXJGeCxIiiDh
	w4OQxK2OtJNqe/7S9FgECutmb2W280EL1jCyImuPPCrPQseiGp1bgWo6XGirm3hP
	6/rpHhOCPZl09c4=
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 10:43:12 +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:	<20140407084312.GA2061@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>
MIME-Version:	1.0
In-Reply-To:	<lhsctu$56e$1@ger.gmane.org>
User-Agent:	Mutt/1.5.21 (2010-09-15)

--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> efficient assembly is available, and so is always a function on x86_64)=
=20
> was not marked __declspec(dllexport/dllimport).
> (See https://github.com/wbhart/mpir/blob/master/gmp-impl.h#L2419 for the=
=20
> current version with the __GMP_DECLSPEC, defined in mpir.h (from gmp-
> h.in) where this gets defined as __declspec(dllimport) for the user=20
> visible header and use outside of MPIR itself)
> It seems that because of this lack, the call to mpn_store from a bunch of=
=20
> test executables produced the wrong callq instruction.
> Once we added the __GMP_DECLSPEC the function got correctly called.
>=20
> 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=20
> __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)
>=20
> As far as dllexport is concerned, we pass --export-all-symbols to ld, and=
=20
> as expected, we don't need the dllexport part when building the library=
=20
> (we get __imp_ and __nm_ symbols for functions).
>=20
> But it seems that the --enable-auto-import counterpart (which should be=
=20
> ld default) is defeated.
> I've had a look at the assembly and objects produced by gcc before linkin=
g=20
> 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=
=20
> magic:
>    100401115:   48 89 c1                mov    %rax,%rcx
>    100401118:   48 8b 05 f1 71 00 00    mov    0x71f1(%rip),%rax        #=
=20
> 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=20
> <__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:

=3D=3D=3D=3D SNIP =3D=3D=3D=3D
$ cat > lib.c <<EOF
#include <stdio.h>

int
foo (int a)
{
  printf ("a =3D %d\n", a);
  return a;
}
EOF
$ cat > app.c <<EOF
#include <stdio.h>

extern int foo (int);

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

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)        # 10040=
7160 <__imp_foo>

Address 100407160 is somewhere within the IAT which gets relocated
at runtime.

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?


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTQmUgAAoJEPU2Bp2uRE+gv48P/0LZqZggn08/V8H14kRJVcRr
3JFVp1lgtUPNQc+apsL74T6Ww9oX03LtItM2rrnRTQWbUWiBWhP99631Zw8rA8fL
hCsswIZ8CRvp/Cs1AcOXCafYMZQ+l8oNdKx0Yo1G9c2lE/V9IkP/0reb+j2nIt8M
z18yZUZ8CfBRK5xstUhRVJGTQiu0YH2itT6dVH8xVHXyPOaVkMxoLV4F8MDhtyXb
PS8QvkCI87np/bbZ53+RVQkuLL2t7VNehxXUp6R5kl15ed4qF8ltOvHXImv9oJtl
yY5VCStz1Y2l/a1+XJuRTdy+Wbmsl9OZ1D7WPMoy13kbi72VYT0mEb7ndg8RZoHG
sRoNSho/kNZccB4aQVbQOxXKL+iuJsu8u9AGCQbxXKkRLn+bTVZ87BiOE0qHv9Vc
13Iakz4rolmc7xkdg2xJAAMMCBWZ31HSDXQatlmcI+fpaPQ2bKqubHVLDe0kgjRC
DfTuJn2cPoJMag0fiOHz9HYTvdR69FvYpyM9RcoZeYmIp+Pz+c/CFatUDaWMylRV
l9ldi90JwjwzR7ct5LZWTCtgBLQ6lEk8Pnmn62SxH4041H9w2W8bKZPTDqD5rnah
2CbSoTypFZ2/DmNkdsRo6bSB+tfqz3NnnU6RgObcy0Lr8GZaVY4LK5ROMtAz4ONn
Nw2zo071AgU8zekUEk54
=ClfB
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--

- Raw text -