From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 931A53858D37; Sun, 7 Jan 2024 14:46:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 931A53858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 931A53858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704638777; cv=none; b=BJ9wIepwV7UjCU5PL0/4C6UaMRdJnYbeFEZNtuirR2tYUewG30HyrcMm9kdFenflyL5WDKkADeOeSEooYEfoFB1WRVvdE4LbswBhlnX5oNJqhOtHILSgbJLdPgyRvpa9Au67SS5KN3n5Zqdi9t1fUoiR9DnJvBpi5d7pbN/DW04= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704638777; c=relaxed/simple; bh=JlyfX69FtQeI6+3tpGjP0acfJA/32pbcC4GayvvcJr8=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=hJQtnufHfv6NIYTZZoZEC53j9VS3r747FJPALgwp9EHY+41dbi4NdRXSCxOOW3oedk/3SfZBSrx5obhukE0/6gZb7Riqiq4tOcQrdDLo8ZmRDclIYhfph/bp3osleKY9gwccBxPDkGRk2P05F9YsJO+LcK6QlHxVot5BegXaSG4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=10VFqgJYGQ+LShvQJbp6UYoc6ETou9jJexd7nodFD0s=; b=ii1rMjPbohCQTg5i3Oie KR4p+M939xLiClCc5RbXzp98ZRYI9Yp0Kwfxzi79kokqpW0elZJPCBI1F1LKSBHS1ydMz/rmX2SMl UkxP0R6RCyv5SRnMrbRfmnAwvmActl42FWebUCBTgmwhKNcVgP2CgxgCxrutOUxfQISMcjtha6+0b TTKRIPZZxRtF6yULvXy4vULI6NyqcNcO9lSDMwH4XKp0vb7544WUvNaZnfE0+3achDkXwxQn2U4IU /YoNeY4ErZ4RTZsG1v2UxAkW2dEgmiiT4gVIPH1NHsafP+vSiKvBWGjsQRBF7jgIRQ4ibAu8EaLfM avZ/7O7Oj/d67w==; Date: Sun, 07 Jan 2024 16:46:07 +0200 Message-Id: <83ttnpqk0g.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Bj=C3=B6rn_Sch=C3=A4pers?= Cc: iant@google.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <4cb3a2a5-c0b3-40c8-b460-f21d65a9aea2@hazardy.de> (message from =?utf-8?Q?Bj=C3=B6rn_Sch=C3=A4pers?= on Sun, 7 Jan 2024 12:58:29 +0100) Subject: Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-4-gcc@hazardy.de> <0c08e584-499f-473f-8699-a41c6a967536@hazardy.de> <863fd658-11e9-455e-9def-8a95217bc98f@hazardy.de> <83bk9xsklk.fsf@gnu.org> <4cb3a2a5-c0b3-40c8-b460-f21d65a9aea2@hazardy.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: [I re-added the other addressees, as I don' think you meant to make this discussion private between the two of us.] > Date: Sun, 7 Jan 2024 12:58:29 +0100 > From: Björn Schäpers > > Am 07.01.2024 um 07:50 schrieb Eli Zaretskii: > >> Date: Sat, 6 Jan 2024 23:15:24 +0100 > >> From: Björn Schäpers > >> Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org > >> > >> This patch adds libraries which are loaded after backtrace_initialize, like > >> plugins or similar. > >> > >> I don't know what style is preferred for the Win32 typedefs, should the code use > >> PVOID or void*? > > > > It doesn't matter, at least not if the source file includes the > > Windows header files (where PVOID is defined). > > > >> + if (reason != /*LDR_DLL_NOTIFICATION_REASON_LOADED*/1) > > > > IMO, it would be better to supply a #define if undefined: > > > > #ifndef LDR_DLL_NOTIFICATION_REASON_LOADED > > # define LDR_DLL_NOTIFICATION_REASON_LOADED 1 > > #endif > > > > I surely can define it. But the ifndef is not needed, since there are no headers > containing the function signatures, structures or the defines: > https://learn.microsoft.com/en-us/windows/win32/devnotes/ldrregisterdllnotification OK, I wasn't sure about that. > >> + if (!GetModuleHandleEx (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS > >> + | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT, > >> + (TCHAR*) notification_data->dll_base, > > > > Is TCHAR correct here? does libbacktrace indeed use TCHAR and relies > > on compile-time definition of UNICODE? (I'm not familiar with the > > internals of libbacktrace, so apologies if this is a silly question.) > > > > Thanks. > > As far as I can see it's the first time for TCHAR, I would've gone for > GetModuleHandleExW, but https://gcc.gnu.org/pipermail/gcc/2023-January/240534.html That was about GetModuleHandle, not about GetModuleHandleEx. For the latter, all Windows versions that support it also support "wide" APIs. So my suggestion is to use GetModuleHandleExW here. However, you will need to make sure that notification_data->dll_base is declared as 'wchar_t *', not 'char *'. If dll_base is declared as 'char *', then only GetModuleHandleExA will work, and you will lose the ability to support file names with non-ASCII characters outside of the current system codepage. > But I didn't want to force GetModuleHandleExA, so I went for TCHAR and > GetModuleHandleEx so it automatically chooses which to use. Same for > GetModuleHandle of ntdll.dll. The considerations for GetModuleHandle and for GetModuleHandleEx are different: the former is also available on old versions of Windows that doesn't support "wide" APIs.