From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70597 invoked by alias); 17 Jul 2019 02:38:38 -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 70553 invoked by uid 89); 17 Jul 2019 02:38:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=H*UA:6.1, H*u:6.1, H*Ad:U*mark X-HELO: m0.truegem.net Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 02:38:30 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id x6H2cSuH071161 for ; Tue, 16 Jul 2019 19:38:28 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpd9Q5zpO; Tue Jul 16 19:38:27 2019 Subject: Re: Question about the ldd output To: cygwin@cygwin.com References: From: Mark Geisert Message-ID: <60ec25fd-9a17-e102-bf5f-e8ec77faefd0@maxrnd.com> Date: Wed, 17 Jul 2019 02:38:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-07/txt/msg00127.txt.bz2 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > Well, I don't think there's anything special that Cygwin does to load executables, because these are essentially Windows processes, so they are loaded by Windows, first and foremost. > > But it gets even weirder. Below are two _consecutive!_ runs of ldd on the very same executable. Why the output differs so drastically (including the unknown dlls all of a sudden)? > > 1. > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000) > cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000) > cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000) > cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000) > cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000) > cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000) > cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000) > cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000) > cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000) > cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000) > ??? => ??? (0xe80000) > ??? => ??? (0x1440000) > ??? => ??? (0xe80000) Briefly, ldd acts as a Windows debugger starting up the given executable. It receives LOAD_DLL_EVENTs from Windows and decodes the event info to print each line of output. The drastically lower memory addresses being shown on the last three lines lead me to speculate these are due to Windows repositioning non-Cygwin DLLs, or maybe Cygwin DLLs rebase doesn't know about, due to address space collisions at their normal load address(es). That said, ldd might be enhanced to show more info in these transient cases. Patches thoughtfully considered... ..mark -- 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