Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries

[Jean-Pierre Flori <jpflori at gmail dot com>]

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