X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:references
	:mime-version:content-type:in-reply-to; q=dns; s=default; b=xXWd
	TG6+0jft87Iov6Brrf6LQ3Br+W/LhiO+mjjKoMJ24toxwANbFM5M2eQ3Ujwj7s2M
	EWeAJPaB1xkHe0tp/Y96xUcXCTjEGx1WQHmRSaV+oHJtA66EdQA7YWj74uo2ZIXU
	+hFVC3p4oVMqF/rdP4qBikcDzEVXU984Su6tyWY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:references
	:mime-version:content-type:in-reply-to; s=default; bh=jB0QzgiDas
	c3ziHz4BvwlMaX9ME=; b=U7Oxf4Ik6Y/oSycr3MHU2K5qsvv7139k+QLPr8aqek
	HybCQSGgSV99wNPoRWOSpdOIhLDMyBOclBa6IJFRQCoj+lGRUfKlY8OfHoV7U5sE
	Zj0TB0sDEkibn9A8SqQ558hZkOE4rzNVLQx90crE+HwHNpbBNTrELdX3J6sIzFnu
	U=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.3 required=5.0 tests=BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*F:D*net.au, H*MI:sk:830e7bc, H*i:sk:830e7bc, million
X-HELO:	mail108.syd.optusnet.com.au
Date:	Sun, 22 May 2016 12:58:43 +1000
From:	Duncan Roe <duncan_roe AT acslink DOT net DOT au>
To:	cygwin AT cygwin DOT com
Subject:	Re: Help debugging a dll issue
Message-ID:	<20160522025843.GE12938@dimstar.local.net>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<b21c0ab1-341b-d6f5-915b-f73973b8079b AT cs DOT umass DOT edu> <830e7bcd-aeb5-264e-6436-799dfa54d7a0 AT cs DOT umass DOT edu>
MIME-Version:	1.0
In-Reply-To:	<830e7bcd-aeb5-264e-6436-799dfa54d7a0@cs.umass.edu>
User-Agent:	Mutt/1.5.22 (2013-10-16)
X-Optus-CM-Score:	0
X-Optus-CM-Analysis:	v=2.1 cv=c+ZWOkJl c=1 sm=1 tr=0 a=+cDhJlqnNvz9E7c5l3ERGg==:117 a=+cDhJlqnNvz9E7c5l3ERGg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=yrkiwgmsf1kA:10 a=_6JL7FwXeeaUyMb0V0YA:9 a=WXOtfqTzyCdGaJHq:21 a=ky0yfbSj1Dh07YzD:21 a=CjuIK1q_8ugA:10
X-IsSubscribed:	yes

On Sat, May 21, 2016 at 07:30:37PM -0400, Eliot Moss wrote:
> 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
>
You surely tried this already: strip --strip-unneeded or --strip-debug?

Cheers ... Duncan.

--
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 -