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/20/2016 9:36 AM, Duncan Roe wrote:
On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote:
On 5/20/2016 7:26 AM, Duncan Roe wrote:

Hi Eliot,

Do you know what is the name of the totally different symbol? (maybe from nm -D)

Yes -- I have been using nm and objdump to examine the relevant files.  The dll
is called libpypy-c.dll.  The symbol I want to bind to is pypy_main_startup, and
its proper value (as returned by nm and objdump) is 0x6410ac60.  The result I
get is the value of symbol pypy_g_PyNumber_Negative (an automatically generated
C function), which is 0x63443f00.

I wonder if these collide in some internal hash table and the hash lookup (or
the table building) is broken in some subtle way.

Regards -- Eliot

Does findit give the same answer for both symbols?

If you could build your library and libdl.a with debug (-g) then you might be
able to see how the lookup goes wrong.

HTH ... Duncan.

Well, the wrong answer comes back from the Windows routine GetProcAddress.  The
bug seems to lie either in the Windows run-time code or in how the dll is being
built.  I am trying giving one of the functions a different name to see what
happens (if it's a hash collision effect, presumably something will show up
different).

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


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