Re: [PATCH 3/4] libbacktrace: work with aslr on windows
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...) - 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
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
On 1/20/23 20:19, Eli Zaretskii wrote: Date: Fri, 20 Jan 2023 17:46:59 +0100 Cc: gcc-patches@gcc.gnu.org, g...@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. Are there even any platforms that have GetModuleHandleA but not GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003 are the first versions to support both of the APIs, so if this is supposed to work on Windows 98, for instance, whether we're using GetModuleHandleA or GetModuleHandleW won't matter. - 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. (just as a clarification, I did not write this patch)
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
On 1/21/23 05:05, Eli Zaretskii wrote: Date: Fri, 20 Jan 2023 21:39:56 +0100 Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org From: Gabriel Ravier - 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. Are there even any platforms that have GetModuleHandleA but not GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003 are the first versions to support both of the APIs, so if this is supposed to work on Windows 98, for instance, whether we're using GetModuleHandleA or GetModuleHandleW won't matter. I'm not sure I follow the logic. A program that calls GetModuleHandleW will refuse to start on Windows that doesn't have that API. So any version before XP is automatically excluded the moment you use code which calls that API directly (i.e. not through a function pointer or somesuch). A program that calls GetModuleHandleA will also refuse to start on Windows if it doesn't have that API. The set of Windows versions that do not have GetModuleHandleA is, according to MSDN, the same as the set of Windows versions that do not have GetModuleHandleW.
