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 <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.
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)

Reply via email to