From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81777 invoked by alias); 21 May 2016 23:30:56 -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 81762 invoked by uid 89); 21 May 2016 23:30:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*MI:sk:b21c0ab, million, skilled, dear X-HELO: csmail.cs.umass.edu Received: from mdc1.cs.umass.edu (HELO csmail.cs.umass.edu) (128.119.240.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 May 2016 23:30:53 +0000 Received: from [192.168.0.144] (rrcs-50-74-66-18.nyc.biz.rr.com [50.74.66.18]) by csmail.cs.umass.edu (Postfix) with ESMTPSA id 6348C580001235E316; Sat, 21 May 2016 19:30:51 -0400 (EDT) Reply-To: moss@cs.umass.edu Subject: Re: Help debugging a dll issue References: To: cygwin From: Eliot Moss Message-ID: <830e7bcd-aeb5-264e-6436-799dfa54d7a0@cs.umass.edu> Date: Sat, 21 May 2016 23:30:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00243.txt.bz2 On 5/19/2016 10:54 PM, Eliot Moss wrote: > Dear Cygwin friends -- > > I am trying to get pypy to build under cygwin. (It used to do so, but > has not been maintained.) I am very close, but there is something quite > odd happening when trying to access the large dll that the system builds: > the first call into that dll goes wild and causes a segfault. The issue > seems to lie with run-time linking, for I can use dlopen to open the dll > and then dlsym to look up the function, and I get the same bad address. > I see nothing wrong from nm and objdump. The dll is about 70 million > bytes long, so I can't really post it, but if you want to have a crack > at this, we can find some mutually agreeable place and I can tell you > the entry point I am trying to access. > > I have found that if I patch the indirection in the associated .exe file > to refer to the actual address of the function, then the program runs, > so it's just this one linkage that is not working (apparently). Very > mysterious to me. I used binary search, eliminating .o files from the .dll on the thought that it was either a particular .o file that was leading to a problem, or possibly the overall size (this is a huge link!). I found that a .dll with 58725 section 1 symbols (as reported by objdump -t) works, and one with 66675 section one symbols fails. So it appears to be a size issue. Is anyone out there skilled enough with gnu ld to guide me as to how to keep that section from getting too big? I tried --split-by-reloc, but that gave no improvement (I don't think it's relocations that are the problem, just the overall size of a section). I'll try --split-by-file, but I am doubting that is the right thing either. In fact, it is looking that the solution may be to get pypy to build its .dll with fewer symbols in the symbol table, perhaps by suitable use of __declspec(dllexport) and __declspec(dllimport), etc. (These are apparently deprecated in favor of __attribute__((visibility("hidden"))), etc., but a number of those generate warnings that the visbility attributes are not supported in this configuration!) Any thoughts from the populace? Regards -- EM -- 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