> Date: Fri, 20 Jan 2023 17:46:59 +0100 > Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > From: Gabriel Ravier <gabrav...@gmail.com> > > On 1/20/23 14:39, Eli Zaretskii via Gcc wrote: > >> From: Björn Schäpers <g...@hazardy.de> > >> 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.
