This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
- From: Jean-Pierre Flori <jpflori at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 7 Apr 2014 09:14:41 +0000 (UTC)
- Subject: Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
- Authentication-results: sourceware.org; auth=none
- 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>
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a ÃcritÂ:
> 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
>> efficient assembly is available, and so is always a function on x86_64)
>> was not marked __declspec(dllexport/dllimport).
>> (See https://github.com/wbhart/mpir/blob/master/gmp-impl.h#L2419 for
>> the current version with the __GMP_DECLSPEC, defined in mpir.h (from
>> gmp- h.in) where this gets defined as __declspec(dllimport) for the
>> user visible header and use outside of MPIR itself)
>> It seems that because of this lack, the call to mpn_store from a bunch
>> of test executables produced the wrong callq instruction.
>> Once we added the __GMP_DECLSPEC the function got correctly called.
>>
>> 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
>> __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)
>>
>> As far as dllexport is concerned, we pass --export-all-symbols to ld,
>> and as expected, we don't need the dllexport part when building the
>> library (we get __imp_ and __nm_ symbols for functions).
>>
>> But it seems that the --enable-auto-import counterpart (which should be
>> ld default) is defeated.
>> I've had a look at the assembly and objects produced by gcc before
>> linking 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
>> magic:
>> 100401115: 48 89 c1 mov %rax,%rcx 100401118:
>> 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:
>> e8 f7 71 00 00 callq 100408310
>> <__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:
>
> ==== SNIP ====
> $ cat > lib.c <<EOF #include <stdio.h>
>
> int foo (int a)
> {
> printf ("a = %d\n", a);
> return a;
> }
> EOF $ cat > app.c <<EOF #include <stdio.h>
>
> extern int foo (int);
>
> int main ()
> {
> int x = foo (42); printf ("x = %d\n", x);
> return 0;
> }
> EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $
> ./app a = 42 x = 42 ==== SNAP ====
>
> 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) #
> 100407160 <__imp_foo>
>
> Address 100407160 is somewhere within the IAT which gets relocated at
> runtime.
For most functions I indeed see this trampoline trick within the binary.
>
> 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?
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I remove all dllimport, the call to the function mpn_addadd_n
also gives a segfault when executing t-addadd_n.exe.
Note that the test t-aors.exe does not segfault, and indeed it only uses
the mpn_add_1 and mpn_sub_1 functions which are not from assembly.
I'll now try to produce a minimal example.
(I've tried GCC 4.7.3 and it gives the same result.)
Best,
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