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
