From: Jean-Pierre Flori <jpflori@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Date: Sun, 06 Apr 2014 20:20:00 -0000 [thread overview]
Message-ID: <lhsctu$56e$1@ger.gmane.org> (raw)
In-Reply-To: <20140402090750.GP2508@calimero.vinschen.de>
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
next prev parent reply other threads:[~2014-04-06 20:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 22:07 Jean-Pierre Flori
2014-04-02 9:07 ` Corinna Vinschen
2014-04-06 20:20 ` Jean-Pierre Flori [this message]
2014-04-07 7:52 ` Achim Gratz
2014-04-07 8:43 ` Corinna Vinschen
2014-04-07 9:14 ` Jean-Pierre Flori
2014-04-07 9:39 ` Corinna Vinschen
2014-04-07 9:55 ` Jean-Pierre Flori
2014-04-07 9:49 ` Jean-Pierre Flori
2014-04-07 10:42 ` Jean-Pierre Flori
2014-04-07 10:45 ` Jean-Pierre Flori
2014-04-07 11:26 ` Jean-Pierre Flori
2014-04-07 11:30 ` Corinna Vinschen
2014-04-07 11:50 ` Jean-Pierre Flori
2014-04-07 11:57 ` Corinna Vinschen
2014-04-07 13:28 ` Jean-Pierre Flori
2014-04-07 14:03 ` Jean-Pierre Flori
2014-04-07 14:36 ` Corinna Vinschen
2014-04-07 14:48 ` Jean-Pierre Flori
2014-04-07 15:39 ` Corinna Vinschen
2014-04-03 13:02 ` Jean-Pierre Flori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='lhsctu$56e$1@ger.gmane.org' \
--to=jpflori@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).