DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=GTrJWt4f+DrpIfmN
	z2KN7WzMqgtDkay9btPbHwi6Bzo6sbUXwcCOWpJYh7BXZSGE94Sjb6zemr1JudnT
	oUXQ+GCNoiKsuBPiNFNK4Vw4W/Q+OcC5NUD2JeEHd9/R/3ArF6hGub14jzhNhWFZ
	00MV05qScuoRD3qIwBYBaKfpN4I=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: Question about the ldd output
To: cygwin@cygwin.com
References: <BN6PR09MB2227BA2644949DB75A67A6B2A5F60@BN6PR09MB2227.namprd09.prod.outlook.com>
From: Mark Geisert <mark@maxrnd.com>
Message-ID: <60ec25fd-9a17-e102-bf5f-e8ec77faefd0@maxrnd.com>
Date: Tue, 16 Jul 2019 19:38:27 -0700
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: <BN6PR09MB2227BA2644949DB75A67A6B2A5F60@BN6PR09MB2227.namprd09.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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