An updated version, using neither A or W, but just the macro.
Am 21.01.2023 um 12:42 schrieb Eli Zaretskii:
Date: Sat, 21 Jan 2023 11:47:42 +0100
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier <gabrav...@gmail.com>
On 1/21/23 05:05, Eli Zaretskii wrote:
Date: Fri, 20 Jan 2023 21:39:56 +0100
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier <gabrav...@gmail.com>
- 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.
MSDN lies (because it wants to pretend that older versions don't
exist). Try this much more useful site:
http://winapi.freetechsecrets.com/win32/WIN32GetModuleHandle.htm
From 52cbe06b1c165172191f66ff7e55a49adecf661d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?= <bjo...@hazardy.de>
Date: Sun, 30 Apr 2023 23:52:37 +0200
Subject: [PATCH 2/3] libbacktrace: work with aslr on windows
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Any underflow which might happen, will be countered by an overflow in
dwarf.c.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/89 and
https://github.com/ianlancetaylor/libbacktrace/issues/82.
* pecoff.c (coff_add): Set the base_address of the module, to
find the debug information on moved applications.
Signed-off-by: Björn Schäpers <bjo...@hazardy.de>
---
libbacktrace/pecoff.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 56af4828e27..9cc13b47947 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE. */
#include "backtrace.h"
#include "internal.h"
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include <windows.h>
+#endif
+
/* Coff file header. */
typedef struct {
@@ -610,6 +622,8 @@ coff_add (struct backtrace_state *state, int descriptor,
int debug_view_valid;
int is_64;
uintptr_t image_base;
+ uintptr_t base_address = 0;
+ uintptr_t module_handle;
struct dwarf_sections dwarf_sections;
*found_sym = 0;
@@ -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) GetModuleHandle (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,
--
2.42.1
