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=OUjr79qkKrXffS1HpT9LveibCiosV325jQVkn9MtvAKHsspwHH1KR
	JzgkIyZrenpVb0LoJ9l1lE5Ug6sMjyIxsP1j9UsOTW8yoJWuvCw0BeQ6eA15MieW
	QNd7Rl7z5FoAPH6pIbXw6Plcnass2wXtsvIlrJsS1MlRvMovldVWfs=
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=SviGARFd4xerK9QPx2nPJ2kl9+c=; b=EAI0090nWDwnVk3LHaAlsmYAjZvw
	pHlLquTjUohodIcU2TK3qPGoK6c+1WWOPzyhILAA34KVxcPkg3SuK8d1eAdvRWhl
	HprLF//vKku/Oqi4q3TqUBwMdZX0exP1voiiAw/Xm4e2RSFRAmD6BFjz7yi/dc8r
	OGb+PHMprjir+9s=
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 16:36:18 +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: <20140407143618.GN2061@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <lhtqa1$ie3$1 AT ger DOT gmane DOT org> <lhtsb6$ie3$2 AT ger DOT gmane DOT org> <lhtve5$ie3$4 AT ger DOT gmane DOT org> <lhtvgh$ie3$5 AT ger DOT gmane DOT org> <lhu212$ie3$6 AT ger DOT gmane DOT org> <20140407113027 DOT GA30595 AT calimero DOT vinschen DOT de> <lhu3dq$ie3$7 AT ger DOT gmane DOT org> <20140407115730 DOT GA721 AT calimero DOT vinschen DOT de> <lhu95j$ie3$8 AT ger DOT gmane DOT org> <lhub63$ie3$9 AT ger DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="vbzKE9fGfpHIBC6T"
Content-Disposition: inline
In-Reply-To: <lhub63$ie3$9@ger.gmane.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On Apr  7 14:02, Jean-Pierre Flori wrote:
> Le Mon, 07 Apr 2014 13:28:19 +0000, Jean-Pierre Flori a =C3=A9crit=C2=A0:
>=20
> > Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a =C3=A9crit=C2=A0:
> >=20
> >> On Apr  7 11:50, Jean-Pierre Flori wrote:
> >>> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a =C3=A9crit=C2=
=A0:
> >>> >=20
> >>> > I'm sorry, but I don't know how this works exactly.  The nm prefix
> >>> > is only added for external references, not for inlined functions,
> >>> > but I don't know the gory details.  You may be better off to ask on
> >>> > the gcc mailing list.
> >>> >=20
> >>> No problem, I've already learned tons of stuff thanks to your help.
> >>> I've just posted on gcc-help.
> >>> http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html
> >>=20
> >> Thanks.  A simple testcase would still be nice, of course.
> >>=20
> >>=20
> > Sure, but it seems the issue is that I cannot get the __nm_ prefix when
> > I elaborate on a minimal problem like you did.
> >=20
> > I'll still try to get something this afternoon.
> I think I got something:
> $ cat > lib.c <<EOF
> #include <stdio.h>
>=20
> int
> foo (int a)
> {
>   printf ("a =3D %d\n", a);
>   return a;
> }
> EOF
> $cat > asm.as <<EOF
> global nothing
> ;export nothing
> nothing:
>   ret
>   end
> 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);
>   nothing();
>   return 0;
> }
> EOF
> $ gcc -g -c lib.c -o lib.o
> $ yasm -fx64 asm.as -o asm.o
> $ gcc -shared lib.o ams.o -Wl,--out-implib=3Dlib.dll.a -Wl,--export-all-
> symbols -o lib.dll
> $ gcc -g -o app app.c -L. -llib
> $ ./app
> ...
> <segfault>
>=20
> Without the export directive (commented above) I get __nm_ prefix and=20
> wrong callq instruction.
> With it, the __nm_prefix disappears and the trampoline correctly used.

I think you must define the export (gas: .def) pseudo op when creating
your own assembler code exporting a symbol from a DLL.  If you look
into the code created by gcc from lib.c:

$ gcc -S lib.c
$ cat lib.s
        .file   "lib.c"
        .section .rdata,"dr"
.LC0:
        .ascii "a =3D %d\12\0"
        .text
        .globl  foo
        .def    foo;    .scl    2;      .type   32;     .endef
        .seh_proc       foo
foo:
        pushq   %rbp
        .seh_pushreg    %rbp
        movq    %rsp, %rbp
        .seh_setframe   %rbp, 0
        subq    $32, %rsp
        .seh_stackalloc 32
        .seh_endprologue
        movl    %ecx, 16(%rbp)
        movl    16(%rbp), %edx
        leaq    .LC0(%rip), %rcx
        call    printf
        movl    16(%rbp), %eax
        addq    $32, %rsp
        popq    %rbp
        ret
        .seh_endproc
        .ident  "GCC: (GNU) 4.8.2"
        .def    printf; .scl    2;      .type   32;     .endef

At this point gcc doesn't know that foo will get exported from a DLL,
but it generates the .def directive nevertheless.  If I create the
same code in gas:

	.text
	.globl nothing
	.def   nothing; .scl 2; .type 32; .endef
nothing:
	ret

then it works, but crashes if I omit the .def directive.  So it seems
to me you don't have to export the symbol using the dllimport/dllexport
directives, but you have to specify the symbol explicitely for export.


Corinna

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

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

iQIcBAEBAgAGBQJTQrfiAAoJEPU2Bp2uRE+gF3oP/0gLEzYz0JkWB4KhzNDF+d/k
2lBl//Hx/WX66l5fAomb//F0S8i9TqRO44qvWSWvsRNMr8Rgvs2OMh/89boNbqjR
7rbwJGPXI+uAVkNHPwjn8CwLdNObbN56ttKcs7lig0ZGabBOqxWUHCPj33NvJyi7
cQ4mgCmdF+A5LD+Aod0vtz0lLgR2KZcgA8fwyQSBCbzGIeoAIpOm/Np3EPRfEs2Y
S7G8N7jqdon2HMUbiL/QTFVz23Z1ckwbvw9r7g0Iktf6zRKkwzlsWuO+ZXPheWuS
AgdEgBJG+kTqNn3WQ1HD8sZ1+ntletrrTxprCox93rZOKx96lFUZr2rNsQ7S2esj
lweyshBOwAJCqOZeex1tDSgQovOTy6AFcTZupiLu2A+5gUhyyzJNKJ4PQ+Iy4Hm/
ihE+7ykuKccOWPT4FCtAvstkhYmwqlBZh4+3w22LMtl+6yNL6J6E7DN4TGXwuXho
o1rQ8ZmPbhshGL1BM7y4pKlkTVSqXjSMiJBp+4RMS/id1fPc6/036XrT2urdZ11a
PxytCUCfWtQmIgv6dED0CoIBwpkLGoSzqZ7vDsOwF7XIL4yPAAqKLR7dtYVRr4Wa
12k+/N6vp9iC7vYi6l98jANbwGyWJs9a9bS2T3FuQKL65V+Cg4w+lu9t8A0DZAE3
pRA3daaIFlzYBuHgXEyn
=hvBV
-----END PGP SIGNATURE-----

--vbzKE9fGfpHIBC6T--