Question about the ldd output

[Brian Inglis]

On 2019-07-09 12:02, Jon Turney wrote:
> On 09/07/2019 17:40, Brian Inglis wrote:
>> On 2019-07-08 12:00, 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)?
> 
> This is probably a 'bug'.
> 
>> Libraries may be loaded asynchronously as they are accessed, and ldd just dumps
>> the dll import table once the subprocess is ready to run.
>> Perhaps these are import entries that ldd should detect and skip or annotate in
>> some more useful way.
> 
> Please don't spread misinformation based upon guessing how Cygwin's ldd works.

The ldd(1) man page documents how it works, and how to get dll info is
documented: the guesses are about how and with what Windows populates the
dll import table, and how ldd may misinterpret it: a slightly more informative
version of "This is probably a 'bug'" ;^>

> It's not necessary, as the source code is available [1] :)
> [1]
> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=history;f=winsup/utils/ldd.cc

Uncommented, undocumented source code with mainly Windows calls is no help to
most of us with little background in Windows development.

David Macek did some debugging and suggested a patch to ignore threads with
entry points in ntdll.dll, but I could not see any followup, response, or
similar patch in the commits or source:
"Re: Why does ldd not show cyg*.dll in its output?"
https://sourceware.org/ml/cygwin/2016-06/msg00478.html

Based on what I see and PE format docs, ldd should iterate over all the
entries in the dll import directory table, until the end or an all zeros/nulls
entry is reached, and the name pointers should all be 32 bit image base relative
addresses, but they are being handled as section relative addresses in
dump_import_directory(), which might amount to the same thing here.

The attached shows the opinions of ldd, cygcheck, and SysInternals listdlls64
run against "$ yes > /dev/null &" process, so a comparison of the first two
might help, but the latter is proprietary closed source and the process is
executing, so may show dlls dynamically loaded by other Windows dlls.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
-------------- next part --------------
$ ldd /bin/yes
	ntdll.dll => /proc/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff88e7a0000)
	KERNEL32.DLL => /proc/cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff88ba30000)
	KERNELBASE.dll => /proc/cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff88b2e0000)
	cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
	cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3d17d0000)
	cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3e21f0000)
$ cygcheck /bin/yes
C:\cygwin64\bin\yes.exe
  C:\cygwin64\bin\cygwin1.dll
    C:\WINDOWS\system32\KERNEL32.dll
      C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\KERNELBASE.dll
      C:\WINDOWS\system32\api-ms-win-core-processthreads-l1-1-1.dll
      C:\WINDOWS\system32\api-ms-win-core-synch-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-file-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-timezone-l1-1-0.dll
      C:\WINDOWS\system32\api-ms-win-core-localization-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-file-l2-1-0.dll
      C:\WINDOWS\system32\api-ms-win-core-xstate-l2-1-0.dll
  C:\cygwin64\bin\cygintl-8.dll
    C:\cygwin64\bin\cygiconv-2.dll
$ listdlls64 yes			# SysInternals Suite
------------------------------------------------------------------------------
yes.exe pid: 7948
Command line: "C:\cygwin64\bin\yes.exe"

Base                Size      Path
0x0000000000400000  0xf000    C:\cygwin64\bin\yes.exe
0x000000008e7a0000  0x1ed000  C:\WINDOWS\SYSTEM32\ntdll.dll
0x000000008ba30000  0xb3000   C:\WINDOWS\System32\KERNEL32.DLL
0x000000008b2e0000  0x293000  C:\WINDOWS\System32\KERNELBASE.dll
0x00000000d17d0000  0x14000   C:\cygwin64\bin\cygintl-8.dll
0x0000000080040000  0x5f0000  C:\cygwin64\bin\cygwin1.dll
0x00000000e21f0000  0x105000  C:\cygwin64\bin\cygiconv-2.dll
0x000000008c090000  0xa3000   C:\WINDOWS\System32\advapi32.dll
0x000000008e350000  0x9e000   C:\WINDOWS\System32\msvcrt.dll
0x000000008c250000  0x9e000   C:\WINDOWS\System32\sechost.dll
0x000000008d9a0000  0x122000  C:\WINDOWS\System32\RPCRT4.dll
0x000000008a190000  0xc000    C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL
0x000000008b680000  0x7e000   C:\WINDOWS\System32\bcryptPrimitives.dll

-------------- next part --------------

--
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