From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118217 invoked by alias); 20 May 2016 13:46:46 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 117356 invoked by uid 89); 20 May 2016 13:46:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:1349, findit, hth, HTH X-HELO: csmail.cs.umass.edu Received: from mdc1.cs.umass.edu (HELO csmail.cs.umass.edu) (128.119.240.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 May 2016 13:46:44 +0000 Received: from [192.168.0.144] (rrcs-50-74-66-18.nyc.biz.rr.com [50.74.66.18]) by csmail.cs.umass.edu (Postfix) with ESMTPSA id B8D7A380000F5E12D2; Fri, 20 May 2016 09:46:42 -0400 (EDT) Reply-To: moss@cs.umass.edu Subject: Re: Help debugging a dll issue References: <3a4d2501-8845-99b6-d58b-544bff5e223f@cs.umass.edu> <20160520112618.GC12938@dimstar.local.net> <20160520133659.GD12938@dimstar.local.net> To: cygwin@cygwin.com From: Eliot Moss Message-ID: <739fe087-4386-3916-84e7-368ac27a5ae0@cs.umass.edu> Date: Fri, 20 May 2016 13:46:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160520133659.GD12938@dimstar.local.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00228.txt.bz2 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