From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.hazardy.de (mail.hazardy.de [78.94.181.132]) by sourceware.org (Postfix) with ESMTPS id 458EA3858D20; Thu, 25 Apr 2024 20:14:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 458EA3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hazardy.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hazardy.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 458EA3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=78.94.181.132 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714076094; cv=none; b=OjhTX9zC5novUAw5e7k6hp8RskHMSn4XniGqBBjjrBzxaiVxFtcj9JKf1NLtznq2iS1OS7+DGgiBaIXfW59vyMQfesQXInS2nfVe57UUYCBotkrraoObECk1y/A9QBMqd0hKgF5PVxe8bJ2i9yRXFghYYEOhYV4TQVOmPh3oXgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714076094; c=relaxed/simple; bh=tjhylYq0PlmwLBMeIEMCC4jiGVyV7jQCiDETAQVyzuA=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=v3G3icsQweyJv81rVc0SBwmYrUniiT7YpLLha9j5ex4UuuSXzN+nJOwHmufSb71BgvxPA3R+sJFneiMIogUqx9ar0hObD0qycuUjlgMJj1uVka8yo+YtQOYViyDTHAh/7YMLenBY5gGyM4WNxPsthyLur1BNn1U0yLwIe3qaUco= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.0.1.129] (hades.hazardy.de [10.0.1.129]) by mail.hazardy.de (Postfix) with ESMTPSA id C7CA17002CE; Thu, 25 Apr 2024 22:14:50 +0200 (CEST) Message-ID: <25fd32ea-72aa-44b9-bbb5-1e58a446231f@hazardy.de> Date: Thu, 25 Apr 2024 22:14:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls From: =?UTF-8?Q?Bj=C3=B6rn_Sch=C3=A4pers?= To: Ian Lance Taylor Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-4-gcc@hazardy.de> <0c08e584-499f-473f-8699-a41c6a967536@hazardy.de> <2bb200e6-2ae7-40b0-86a7-24a72532924c@hazardy.de> Content-Language: de-DE In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am 15.03.2024 um 21:40 schrieb Björn Schäpers: > Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor: >> On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: >>> >>> Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: >>>> On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: >>>>> >>>>> Am 03.01.2024 um 00:12 schrieb Björn Schäpers: >>>>>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: >>>>>>> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: >>>>>>>> >>>>>>>> From: Björn Schäpers >>>>>>>> >>>>>>>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except >>>>>>>> that libraries loaded after the backtrace_initialize are not handled. >>>>>>>> But as far as I can see that's the same for elf. >>>>>>> >>>>>>> Thanks, but I don't want a patch that loops using goto statements. >>>>>>> Please rewrite to avoid that.  It may be simpler to call a function. >>>>>>> >>>>>>> Also starting with a module count of 1000 seems like a lot.  Do >>>>>>> typical Windows programs load that many modules? >>>>>>> >>>>>>> Ian >>>>>>> >>>>>>> >>>>>> >>>>>> Rewritten using a function. >>>>>> >>>>>> If that is commited, could you attribute that commit to me (--author="Björn >>>>>> Schäpers ")? >>>>>> >>>>>> Thanks and kind regards, >>>>>> Björn. >>>>> >>>>> I noticed that under 64 bit libraries loaded with LoadLibrary were missing. >>>>> EnumProcessModules stated the correct number of modules, but did not fill the >>>>> the HMODULEs, but set them to 0. While trying to investigate I noticed if I do >>>>> the very same thing from main (in C++) I even got fewer module HMODULEs. >>>>> >>>>> So I went a different way. This detects all libraries correctly, in 32 and 64 >>>>> bit. The question is, if it should be a patch on top of the previous, or >>>>> should >>>>> they be merged, or even only this solution and drop the EnumProcessModules >>>>> variant? >>>> >>>> Is there any reason to use both patches?  Seems simpler to just use >>>> this one if it works.  Thanks. >>>> >>>> Ian >>> >>> This one needs the tlhelp32 header and its functions, which are (accoridng to >>> the microsoft documentation) are only available since Windows XP rsp. Windows >>> Server 2003. >>> >>> If that's no problem, and in my opinion it shouldn't be, then I can basically >>> drop patch 4 and rebase this one. >> >> I don't see that as a problem.  It seems like the patch will fall back >> cleanly on ancient Windows and simply fail to pick up other loaded >> DLLs.  I think that is fine.  I'll look for an updated patch.  Thanks. >> >> Ian > > Attached is the combined version of the two patches, only implementing the > variant with the tlhelp32 API. > > Tested on x86 and x86_64 windows. > > Kind regards, > Björn. A friendly ping.