Re: Question about the ldd output

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

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.

Attachment: y.txt
Description: Text document

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