From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25681 invoked by alias); 10 Jul 2019 22:55:10 -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 25458 invoked by uid 89); 10 Jul 2019 22:55:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=proprietary, spread X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Jul 2019 22:55:07 +0000 Received: from [192.168.1.114] ([24.64.172.44]) by shaw.ca with ESMTP id lLUOhEpTDUIS2lLUPhZ4uJ; Wed, 10 Jul 2019 16:55:06 -0600 From: Brian Inglis Subject: Re: Question about the ldd output Reply-To: Brian.Inglis@SystematicSw.ab.ca To: cygwin@cygwin.com References: Openpgp: preference=signencrypt Message-ID: <8841099f-6294-4aa7-9615-b42eda332573@SystematicSw.ab.ca> Date: Wed, 10 Jul 2019 22:55:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------817BE2C1142F03618BE050CC" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00079.txt.bz2 --------------817BE2C1142F03618BE050CC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-length: 2637 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. --------------817BE2C1142F03618BE050CC Content-Type: text/plain; charset=UTF-8; name="y.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="y.txt" Content-length: 2880 JCBsZGQgL2Jpbi95ZXMKCW50ZGxsLmRsbCA9PiAvcHJvYy9jeWdkcml2ZS9j L1dJTkRPV1MvU1lTVEVNMzIvbnRkbGwuZGxsICgweDdmZjg4ZTdhMDAwMCkK CUtFUk5FTDMyLkRMTCA9PiAvcHJvYy9jeWdkcml2ZS9jL1dJTkRPV1MvU3lz dGVtMzIvS0VSTkVMMzIuRExMICgweDdmZjg4YmEzMDAwMCkKCUtFUk5FTEJB U0UuZGxsID0+IC9wcm9jL2N5Z2RyaXZlL2MvV0lORE9XUy9TeXN0ZW0zMi9L RVJORUxCQVNFLmRsbCAoMHg3ZmY4OGIyZTAwMDApCgljeWd3aW4xLmRsbCA9 PiAvdXNyL2Jpbi9jeWd3aW4xLmRsbCAoMHgxODAwNDAwMDApCgljeWdpbnRs LTguZGxsID0+IC91c3IvYmluL2N5Z2ludGwtOC5kbGwgKDB4M2QxN2QwMDAw KQoJY3lnaWNvbnYtMi5kbGwgPT4gL3Vzci9iaW4vY3lnaWNvbnYtMi5kbGwg KDB4M2UyMWYwMDAwKQokIGN5Z2NoZWNrIC9iaW4veWVzCkM6XGN5Z3dpbjY0 XGJpblx5ZXMuZXhlCiAgQzpcY3lnd2luNjRcYmluXGN5Z3dpbjEuZGxsCiAg ICBDOlxXSU5ET1dTXHN5c3RlbTMyXEtFUk5FTDMyLmRsbAogICAgICBDOlxX SU5ET1dTXHN5c3RlbTMyXG50ZGxsLmRsbAogICAgICBDOlxXSU5ET1dTXHN5 c3RlbTMyXEtFUk5FTEJBU0UuZGxsCiAgICAgIEM6XFdJTkRPV1Ncc3lzdGVt MzJcYXBpLW1zLXdpbi1jb3JlLXByb2Nlc3N0aHJlYWRzLWwxLTEtMS5kbGwK ICAgICAgQzpcV0lORE9XU1xzeXN0ZW0zMlxhcGktbXMtd2luLWNvcmUtc3lu Y2gtbDEtMi0wLmRsbAogICAgICBDOlxXSU5ET1dTXHN5c3RlbTMyXGFwaS1t cy13aW4tY29yZS1maWxlLWwxLTItMC5kbGwKICAgICAgQzpcV0lORE9XU1xz eXN0ZW0zMlxhcGktbXMtd2luLWNvcmUtdGltZXpvbmUtbDEtMS0wLmRsbAog ICAgICBDOlxXSU5ET1dTXHN5c3RlbTMyXGFwaS1tcy13aW4tY29yZS1sb2Nh bGl6YXRpb24tbDEtMi0wLmRsbAogICAgICBDOlxXSU5ET1dTXHN5c3RlbTMy XGFwaS1tcy13aW4tY29yZS1maWxlLWwyLTEtMC5kbGwKICAgICAgQzpcV0lO RE9XU1xzeXN0ZW0zMlxhcGktbXMtd2luLWNvcmUteHN0YXRlLWwyLTEtMC5k bGwKICBDOlxjeWd3aW42NFxiaW5cY3lnaW50bC04LmRsbAogICAgQzpcY3ln d2luNjRcYmluXGN5Z2ljb252LTIuZGxsCiQgbGlzdGRsbHM2NCB5ZXMJCQkj IFN5c0ludGVybmFscyBTdWl0ZQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KeWVzLmV4ZSBwaWQ6IDc5NDgKQ29tbWFuZCBsaW5lOiAiQzpc Y3lnd2luNjRcYmluXHllcy5leGUiCgpCYXNlICAgICAgICAgICAgICAgIFNp emUgICAgICBQYXRoCjB4MDAwMDAwMDAwMDQwMDAwMCAgMHhmMDAwICAgIEM6 XGN5Z3dpbjY0XGJpblx5ZXMuZXhlCjB4MDAwMDAwMDA4ZTdhMDAwMCAgMHgx ZWQwMDAgIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsCjB4MDAwMDAw MDA4YmEzMDAwMCAgMHhiMzAwMCAgIEM6XFdJTkRPV1NcU3lzdGVtMzJcS0VS TkVMMzIuRExMCjB4MDAwMDAwMDA4YjJlMDAwMCAgMHgyOTMwMDAgIEM6XFdJ TkRPV1NcU3lzdGVtMzJcS0VSTkVMQkFTRS5kbGwKMHgwMDAwMDAwMGQxN2Qw MDAwICAweDE0MDAwICAgQzpcY3lnd2luNjRcYmluXGN5Z2ludGwtOC5kbGwK MHgwMDAwMDAwMDgwMDQwMDAwICAweDVmMDAwMCAgQzpcY3lnd2luNjRcYmlu XGN5Z3dpbjEuZGxsCjB4MDAwMDAwMDBlMjFmMDAwMCAgMHgxMDUwMDAgIEM6 XGN5Z3dpbjY0XGJpblxjeWdpY29udi0yLmRsbAoweDAwMDAwMDAwOGMwOTAw MDAgIDB4YTMwMDAgICBDOlxXSU5ET1dTXFN5c3RlbTMyXGFkdmFwaTMyLmRs bAoweDAwMDAwMDAwOGUzNTAwMDAgIDB4OWUwMDAgICBDOlxXSU5ET1dTXFN5 c3RlbTMyXG1zdmNydC5kbGwKMHgwMDAwMDAwMDhjMjUwMDAwICAweDllMDAw ICAgQzpcV0lORE9XU1xTeXN0ZW0zMlxzZWNob3N0LmRsbAoweDAwMDAwMDAw OGQ5YTAwMDAgIDB4MTIyMDAwICBDOlxXSU5ET1dTXFN5c3RlbTMyXFJQQ1JU NC5kbGwKMHgwMDAwMDAwMDhhMTkwMDAwICAweGMwMDAgICAgQzpcV0lORE9X U1xTWVNURU0zMlxDUllQVEJBU0UuRExMCjB4MDAwMDAwMDA4YjY4MDAwMCAg MHg3ZTAwMCAgIEM6XFdJTkRPV1NcU3lzdGVtMzJcYmNyeXB0UHJpbWl0aXZl cy5kbGwKCg== --------------817BE2C1142F03618BE050CC Content-Type: text/plain; charset=us-ascii Content-length: 219 -- 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 --------------817BE2C1142F03618BE050CC--