From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bcP8E0dOa2AZNAAAWB0awg (envelope-from ) for ; Mon, 05 Apr 2021 13:52:07 -0400 Received: by simark.ca (Postfix, from userid 112) id 44E8C1E789; Mon, 5 Apr 2021 13:52:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6B6F61E590 for ; Mon, 5 Apr 2021 13:52:06 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B0BE9385803F; Mon, 5 Apr 2021 17:52:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0BE9385803F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617645125; bh=PGYrXBjH7oEQiOvyFmBJbZfGgarohwNvkd9p1/sy55o=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=eP8US5keW3XgXeIwBmb60oZx5ife3hDiRRYZWqqMNkUU5QaIYyYoJri5DKNq5quth uEsJN5XoY8ky+FzoqAxQzw4ucYpauGt0gYx7TLo8yM/EAlRmh6jHnRIMIyWItkHNzT QFdCvepdLApSiKkonAxs6AwVT/iyP5ym8OomvF40= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 8942E385803F for ; Mon, 5 Apr 2021 17:52:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8942E385803F Received: from fencepost.gnu.org ([2001:470:142:3::e]:34213) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lTTOL-0007Ql-KQ; Mon, 05 Apr 2021 13:52:01 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3279 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lTTOJ-0003MH-CM; Mon, 05 Apr 2021 13:52:00 -0400 Date: Mon, 05 Apr 2021 20:51:53 +0300 Message-Id: <83y2dwbow6.fsf@gnu.org> To: ssbssa@yahoo.de (Hannes Domani) In-Reply-To: <259022839.1083386.1615397702855@mail.yahoo.com> (ssbssa@yahoo.de) Subject: Re: Subtle problems with "info sharedlibrary" on MS-Windows References: <83czw7p4nd.fsf@gnu.org> <777379173.1335754.1615393830518@mail.yahoo.com> <83mtvbne96.fsf@gnu.org> <259022839.1083386.1615397702855@mail.yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > From: ssbssa@yahoo.de (Hannes Domani) > Date: Wed, 10 Mar 2021 17:35:02 +0000 (UTC) > > Am Mittwoch, 10. März 2021, 17:51:43 MEZ hat Eli Zaretskii Folgendes geschrieben: > > > > Date: Wed, 10 Mar 2021 16:30:30 +0000 (UTC) > > > From: Hannes Domani > > > > > > > . Some DLLs loaded explicitly via LoadLibrary don't show.? I stepped > > > > through the code which loads them and verified they load > > > > successfully; moreover, Process Explorer does show them loaded. > > > > But they are nowhere to be seem in "info sharedlibrary"s display. > > > > > > > > . The "From" address shown by "info sharedlibrary" is different from > > > > the base address at which the DLL is loaded: it is 4KB higher than > > > > the base address. > > > > > > > > Are these problems known? I searched Bugzilla, but didn't find > > > > anything pertinent. > > > > [...] > > For the first problem, I don't have an easy reproducer. The only > > situation where I saw it was in the native-comp branch of GNU Emacs, > > which uses libgccjit to compile Lisp files into DLLs, then loads them > > at run time. If you can build that branch of Emacs, I can tell you > > how to reproduce the first problem using that build. However, maybe > > you could see it also in other executables, if you carefully compare > > what GDB reports against Process Explorer. > > Building Emacs is a bit too much for me right now, but I will see if I notice > it when I debug some other programs. I found an old bug report in Bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=17659 That bug describes the same problem and provides a patch. The bug was closed without applying the because the problem was deemed resolved by the addition of windows_add_all_dlls function to windows-nat.c. However, AFAIU windows_add_all_dlls solves the problem only for DLLs loaded at startup of the debuggee. It cannot solve the problem of DLLs loaded dynamically by the debuggee at run time. Which is what happens in Emacs built with native-compilation capability: it compiles Lisp into shared libraries, and loads those shared libraries as needed. The problem clearly shows itself if you enable debugevents: GDB reports some of the LOAD_DLL_DEBUG_EVENT's without announcing the name of the loaded DLL. Later you can see that the DLL is not in the list shown by "info shared", although Process Explorer shows that DLL as being loaded by the debuggee. So I've reopened that bug, and I hope the patch there can be applied to GDB some time soon. Thanks.