From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vV5/GiP5SGCCJgAAWB0awg (envelope-from ) for ; Wed, 10 Mar 2021 11:51:47 -0500 Received: by simark.ca (Postfix, from userid 112) id 5EA7B1EF78; Wed, 10 Mar 2021 11:51:47 -0500 (EST) 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 6BE6A1E54D for ; Wed, 10 Mar 2021 11:51:46 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 63C8E383F841; Wed, 10 Mar 2021 16:51:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63C8E383F841 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1615395105; bh=4ZjcYFNTeZJZ4PisOSqp4Swz4q1QTWxH8iQcqLJSEdw=; 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=OADr3yCRfwAaAEtzdm+3Jd9XUHCLRF5wdUJQAvVBkhoCQeWML8WXK2X9tmtFICLv3 sFYPe+QMAa2XOGEAKa+4pXmuTreWRh4fHWq/iWWpvCDs0AaJ0EmT75gGJ5/H5u2I9B QQKtl1tFpd3qxWPWxm7cGwQrVwajKQVKNF7D0ygc= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 5E3A3386F839 for ; Wed, 10 Mar 2021 16:51:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5E3A3386F839 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37568) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lK23h-00045Z-3m; Wed, 10 Mar 2021 11:51:41 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3698 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lK23b-0002FJ-CT; Wed, 10 Mar 2021 11:51:37 -0500 Date: Wed, 10 Mar 2021 18:51:33 +0200 Message-Id: <83mtvbne96.fsf@gnu.org> To: Hannes Domani In-Reply-To: <777379173.1335754.1615393830518@mail.yahoo.com> (message from Hannes Domani on Wed, 10 Mar 2021 16:30:30 +0000 (UTC)) Subject: Re: Subtle problems with "info sharedlibrary" on MS-Windows References: <83czw7p4nd.fsf@gnu.org> <777379173.1335754.1615393830518@mail.yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 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" > 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. > > I'm not aware of these kind of problems. > Is there any way I can try to reproduce this? The second one is easy: just debug any program that loads DLLs, either because it requires them or loads them dynamically with LoadLibrary. For example, debug gdb.exe itself, type "start", and then "info shared". You will see that the From address of each DLL ends in "1000". Now start Process Explorer and look at the Image Base or Base address of those same DLLs: you will see it is 1000 hex (4096 decimal) lower than what GDB shows, i.e. the image start address ends in 0000, being 64KB aligned. (I found this because AFAIU the handle returned by LoadLibrary is the starting address where the DLL is loaded, and I saw the 4K mismatch between that handle and what GDB was reporting as the starting address.) 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. Thanks.