Help debugging a dll issue

[Eliot Moss]

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