This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about the ldd output

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]

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

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]