This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help debugging a dll issue

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]