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 9B0923858C00; Fri, 20 Jan 2023 19:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9B0923858C00 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.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=sWKl37lTmf8Bn5w8/it1yGBmgDtqX+fk8i/5WtAdcoA=; b=PJAS30iIefJTWXzjbO7e IYjKWX1TOz5VT8XF/5TG+JIOPdpq/gfDgrqiQ2ib0k7C29bA4I9vQl4tpi+wzVWVh+2N6pUlDjqs9 yNqiwbaEa+s/NehdS5/amdFIpURX8TOSm5C4IGogxvSyiqdLk5OhAsCkjvzKWxskub8h9cqneKj1L 8a5mu3EiNeSQ76fgzpTddstleVEQQVqfis45OwULMjd/UzZAsipw3MTFxVISSVE6McQcbKyC17rn1 nDwhZ4a7D0Jcsn0BQ77it91UfueOXMdyfaQfF9jE2L6/1Pf0zdO17XHP1b24avGA90RsEYifcedGx /BCJSQJ3EK/O+w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIwvX-0001r4-Og; Fri, 20 Jan 2023 14:19:52 -0500 Date: Fri, 20 Jan 2023 21:19:53 +0200 Message-Id: <83k01hm2sm.fsf@gnu.org> From: Eli Zaretskii To: Gabriel Ravier Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: (message from Gabriel Ravier on Fri, 20 Jan 2023 17:46:59 +0100) Subject: Re: [PATCH 3/4] libbacktrace: work with aslr on windows References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-3-gcc@hazardy.de> <83zgadmik1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Fri, 20 Jan 2023 17:46:59 +0100 > Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org > From: Gabriel Ravier > > On 1/20/23 14:39, Eli Zaretskii via Gcc wrote: > >> From: Björn Schäpers > >> Date: Fri, 20 Jan 2023 11:54:08 +0100 > >> > >> @@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor, > >> + (sections[i].offset - min_offset)); > >> } > >> > >> - if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections, > >> +#ifdef HAVE_WINDOWS_H > >> + module_handle = (uintptr_t) GetModuleHandleW (NULL); > >> + base_address = module_handle - image_base; > >> +#endif > >> + > >> + if (!backtrace_dwarf_add (state, base_address, &dwarf_sections, > >> 0, /* FIXME: is_bigendian */ > >> NULL, /* altlink */ > >> error_callback, data, fileline_fn, > > Why do you force using the "wide" APIs here? Won't GetModuleHandle do > > the job, whether it resolves to GetModuleHandleA or GetModuleHandleW? > > I would expect the reason to be either that: > > - using wide APIs with Windows is generally considered to be a best > practice, even when not strictly needed (and in this case I can't see > any problem with doing so, unless maybe we want to code to work with > Windows 95 or something like that...) There's no reason to forcibly break GDB on platforms where wide APIs are not available. > - using the narrow API somehow has an actual drawback, for example maybe > it might not work if the name of the exe file the NULL will tell it to > get a handle to contains wide characters Native Windows port of GDB doesn't support Unicode file names anyway, which is why you used the *A APIs elsewhere in the patch, and rightfully so. So there's no reason to use "wide" APIs in this one place, and every reason not to.