This is the mail archive of the
mailing list for the Cygwin project.
Fwd: Re: Help debugging a dll issue
- From: Eliot Moss <moss at cs dot umass dot edu>
- To: cygwin <cygwin at cygwin dot com>
- Date: Sat, 21 May 2016 23:15:01 -0400
- Subject: Fwd: Re: Help debugging a dll issue
- Authentication-results: sourceware.org; auth=none
- References: <1781b970-23ef-8e8b-ccbb-0e63d09eef2e at cs dot umass dot edu>
- Reply-to: moss at cs dot umass dot edu
(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 <firstname.lastname@example.org>
To: Duncan Roe <email@example.com>
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple