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=yOsLD+bPyk/IfPNb0n949h0UiQoLEYBcIKk9kvHtuUimYw1wTPjWz
	dZoylmIH59ZUvBRUngBN3QHbRew5ORUZD4D9Ct1pRmyoreodQZXoJuXgVpHCB0yQ
	PWg0z70sn+vfq0nq3DlIb3S25C5fqc1G3fEvQ+jcPRMliiLD/UkaP8=
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=Iy5eDMmzvE5kCfRXL4rO+AjdbbI=; b=FeoJcDnYDppA8vKpRsutUomyrzLX
	WOIbjbWb/QMKhv89y5985VyDyytupz+ccFclTEBS28sYCQpQXvx7EyD4AsdcEcDb
	Wq5t2XwWr70rv7x+ySV+z2iNJlaBVl4voVdsKimSzQhMNKs5vHHXyAxJ1GmaWZfU
	vlISZvZt1QfP154=
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=-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 <jpflori AT gmail DOT com>
Subject: Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Date: Mon, 7 Apr 2014 14:47:57 +0000 (UTC)
Lines: 97
Message-ID: <lhudqt$m6e$1@ger.gmane.org>
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>	<20140407143618 DOT GN2061 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 16:36:18 +0200, Corinna Vinschen a écrit :

> On Apr  7 14:02, Jean-Pierre Flori wrote:
>> Le Mon, 07 Apr 2014 13:28:19 +0000, Jean-Pierre Flori a écrit :
>> 
>> > Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
>> > 
>> >> On Apr  7 11:50, Jean-Pierre Flori wrote:
>> >>> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
>> >>> > 
>> >>> > 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.
>> >>> > 
>> >>> 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
>> >> 
>> >> Thanks.  A simple testcase would still be nice, of course.
>> >> 
>> >> 
>> > Sure, but it seems the issue is that I cannot get the __nm_ prefix
>> > when I elaborate on a minimal problem like you did.
>> > 
>> > I'll still try to get something this afternoon.
>> I think I got something:
>> $ cat > lib.c <<EOF #include <stdio.h>
>> 
>> int foo (int a)
>> {
>>   printf ("a = %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>
>> 
>> extern int foo (int);
>> 
>> int main ()
>> {
>>   int x = foo (42); printf ("x = %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=lib.dll.a -Wl,--export-all-
>> symbols -o lib.dll $ gcc -g -o app app.c -L. -llib $ ./app ...
>> <segfault>
>> 
>> Without the export directive (commented above) I get __nm_ prefix and
>> 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 = %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.
> 
Exactly!
I came to the same conclusion.
On top of that, it seems that including the export stuff does not hurt 
when building and linking a static lib.

What's strange is that when we use the dllimport magic then it works even 
though the symbol was not explicitely exported.

Thanks for the support.
JP


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