This is the mail archive of the
mailing list for the Cygwin project.
Re: Help debugging a dll issue
- From: Duncan Roe <duncan_roe at acslink dot net dot au>
- To: cygwin at cygwin dot com
- Date: Sun, 22 May 2016 12:58:43 +1000
- Subject: Re: Help debugging a dll issue
- Authentication-results: sourceware.org; auth=none
- References: <b21c0ab1-341b-d6f5-915b-f73973b8079b at cs dot umass dot edu> <830e7bcd-aeb5-264e-6436-799dfa54d7a0 at cs dot umass dot edu>
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple