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:subject:reply-to:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Etev7rEyRtKjroPR
	kQAcMk85Iqro4gjnZxHdtCfs+qiU68E4NstzXVo+Afqs9bNpsi7RpfXkBpk0iClT
	N+wpF333W2/UF81Jkvqz/IzrmFXADKTrBkOgDpUoIEB3srbSQitmMZS6gva+w7nx
	+NI1jBHa2UuaGkkSqdisZ9w6NqY=
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:subject:reply-to:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=7f7RNhvAtt2BsNg1KM8Esl
	GCC78=; b=lhlbqfu314HbqhiXgdnOH6oLukEWAeQPcwXzMwtKmlbwuV3Bi+0RUA
	m3PdVd1dbCH6e9hZXzdPrP0PajodhuDeZ5docO28ZhKxxNlYuvtCPB+0NOJOKfvW
	QnrOYicvNgc6p7fru1luLl8LNXbm+AriA/swzY8bTeAAuUdBylgho=
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.4 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=D*cs.umass.edu, D*umass.edu, moss AT cs DOT umass DOT edu, U*moss
X-HELO:	csmail.cs.umass.edu
Subject:	Fwd: Re: Help debugging a dll issue
Reply-To:	moss AT cs DOT umass DOT edu
References:	<1781b970-23ef-8e8b-ccbb-0e63d09eef2e AT cs DOT umass DOT edu>
To:	cygwin <cygwin AT cygwin DOT com>
From:	Eliot Moss <moss AT cs DOT umass DOT edu>
X-Forwarded-Message-Id:	<1781b970-23ef-8e8b-ccbb-0e63d09eef2e AT cs DOT umass DOT edu>
Message-ID:	<3c5c59da-a72e-b756-6395-f134e6f34614@cs.umass.edu>
Date:	Sat, 21 May 2016 23:15:01 -0400
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:	<1781b970-23ef-8e8b-ccbb-0e63d09eef2e@cs.umass.edu>
X-IsSubscribed:	yes

(Sorry for top post: meant to send this to the list
in the first place ... EM)


-------- Forwarded Message --------
Subject: Re: Help debugging a dll issue
Date: Sat, 21 May 2016 23:14:09 -0400
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Reply-To: moss AT cs DOT umass DOT edu
To: Duncan Roe <duncan_roe AT acslink DOT net DOT au>

On 5/21/2016 10:58 PM, Duncan Roe wrote:
> 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?

A helpful thought, but no, it did not occur to me.  Getting pypy to run
that extra step in the middle of its build would involve hacking its process
of generating a Makefile, while it already had __declspec handling for the
Windows native build case, so it made sense to me to go that way for this
application -- but I'll file that away for future use!

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

- Raw text -