From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21443 invoked by alias); 7 Apr 2014 09:49:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 21432 invoked by uid 89); 7 Apr 2014 09:49:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 07 Apr 2014 09:49:49 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WX6BV-00026A-JX for cygwin@cygwin.com; Mon, 07 Apr 2014 11:49:45 +0200 Received: from cer78-1-88-174-56-78.fbx.proxad.net ([88.174.56.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 11:49:45 +0200 Received: from jpflori by cer78-1-88-174-56-78.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 11:49:45 +0200 To: cygwin@cygwin.com From: Jean-Pierre Flori Subject: Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries Date: Mon, 07 Apr 2014 09:49:00 -0000 Message-ID: References: <20140402090750.GP2508@calimero.vinschen.de> <20140407084312.GA2061@calimero.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00097.txt.bz2 Le Mon, 07 Apr 2014 09:14:41 +0000, Jean-Pierre Flori a écrit : > 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. > It seems the dll produced at least has different treatment for these tow kinds of functions. jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep store 00000004ff238170 T __gmpn_store 00000004ff238198 t __gmpn_store.1 00000004ff2381a0 t __gmpn_store.2 00000004ff2381b3 t __gmpn_store.3 00000004ff2381bd t __gmpn_store.4 00000004ff2381be t __gmpn_store.5 00000004ff2381c3 t __gmpn_store.6 00000004ff2381c9 t __gmpn_store.7 ... jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep addadd_n 00000004ff208e10 T __gmpn_addadd_n 00000004ff208e50 t __gmpn_addadd_n.1 00000004ff208eac t __gmpn_addadd_n.2 00000004ff208ebe t __gmpn_addadd_n.3 00000004ff208f0f t __gmpn_addadd_n.4 00000004ff208f54 t __gmpn_addadd_n.5 00000004ff208f6e t __gmpn_addadd_n.6 jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep add_1 00000004ff207d40 T __gmpn_add_1 And jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep add_1 0000000000000000 T __gmpn_add_1 0000000000000000 I __imp___gmpn_add_1 jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep addadd_n 0000000000000000 I __imp___gmpn_addadd_n 0000000000000000 I __nm___gmpn_addadd_n -- 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