Mail Archives: cygwin/2014/04/06/16:20:51
Dear all,
Le Wed, 02 Apr 2014 11:07:50 +0200, Corinna Vinschen a écrit :
> On Apr 2 00:07, Jean-Pierre Flori wrote:
>> Dear all,
>>
>> It's amazing to see how well Cygwin64 is going.
>> Thanks for your hard work.
>>
>> While preparing the new MPIR release, which will be the first one to
>> support Cygwin4, we encountered problems running MPIR testsuite when
>> MPIR was configured to produce a shared lib.
>> That's with latest cygwin/binutils/gcc/g++ from today.
>>
>> It seems that a call to the MPN_ZERO macro, which on my setup is at
>> 0x4ff2746c0 in the shared lib but we get the instruction:
>> callq 0xff2746c0
>
> This looks suspicious. On x86_64 this kind of instruction is usually
> PC-relative or uses a jump table, because x86_64 uses the small code
> model by default (medium model on Cygwin).
>
>> within the test binary and that yields a nice segfault.
>> Please see
>> https://groups.google.com/d/msg/mpir-devel/KzsxIWhVx8A/EAUoP4ybWOMJ and
>> the few following post for more details.
>>
>> For sure, we don't get what's going on here.
>> Would you have any clue?
>
> Not without a more detailed report. The aforementioned link does not
> contain pointers to the source, for instance. Also, a simple testcase
> might be helpful.
>
> If you suspect a linker bug, you might contemplate to ask on the
> binutils mailing list binutils AT sourceware DOT org which is where ld
> is maintained.
>
Here come more details as I've taken a little more time to try to
understand what was happening.
The problem arosed when running the tests for MPIR.
The latest alpha is available at http://mpir.org/
Currently it's 2.7.alpha4: http://mpir.org/mpir-2.7.0-alpha4.tar.bz2
Note that thanks to your kind support, MPIR should now build correctly on
Cygwin64 (with or without C++ support).
That's already great!
(And that might help you to take a look at our problem if you feel
inclined to do it.)
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.
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>
I've tested the same modifications on Cygwin32 and not putting in the
dllimport stuff (or if you prefer, defining __GMP_DECLSPEC to be empty) is
no problem.
Let's go through the same t-neg file, but use another function as
mpn_store is a macro on my 32 bit Cygwin.
In assembly with dllimport:
movl %eax, (%esp)
movl __imp____gmp_randinit_default, %eax
call *%eax
without dllimport:
movl %eax, (%esp)
call ___gmp_randinit_default
In object file:
23: 89 04 24 mov %eax,(%esp)
26: a1 00 00 00 00 mov 0x0,%eax
2b: ff d0 call *%eax
vs:
23: 89 04 24 mov %eax,(%esp)
26: e8 00 00 00 00 call 2b <_main+0x2b>
In exe file:
4011b3: 89 04 24 mov %eax,(%esp)
4011b6: a1 74 71 40 00 mov 0x407174,%eax
4011bb: ff d0 call *%eax
vs:
4011b3: 89 04 24 mov %eax,(%esp)
4011b6: e8 8d 13 00 00 call 402548
<___gmp_randinit_default>
I'm also trying to get GCC 4.7.3 rebuilt to see if it makes any
difference with GCC 4.8.2.
Any advice would be welcomed!
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
- Raw text -