DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=bkquet+2DZAPShsY
	++bvhj4aChg2sGQVARvzwkkfk/NLhYvnhRa7tLUVtXrC74qM5AYQnysRZ/6tAOmO
	Ro5ThKdAVqeDHu6WQ3ZIVdo0gbQaBT/RCLM3qZRD0z0Uqw7kgs0L46eaDA6a87b6
	FtN0rvFEo36QkhLJZmPXx3NOtco=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Reply-To: moss AT cs DOT umass DOT edu
Subject: Re: Help debugging a dll issue
References: <b21c0ab1-341b-d6f5-915b-f73973b8079b AT cs DOT umass DOT edu>
To: cygwin <cygwin AT cygwin DOT com>
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID: <830e7bcd-aeb5-264e-6436-799dfa54d7a0@cs.umass.edu>
Date: Sat, 21 May 2016 19:30:37 -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: <b21c0ab1-341b-d6f5-915b-f73973b8079b@cs.umass.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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