Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, May 2, 2024 at 12:23 PM Björn Schäpers wrote: > > Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor: > > > > Which of your other patches are still relevant? Thanks. > > > only this one. Thanks. Committed. Ian
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, May 2, 2024 at 12:23 PM Björn Schäpers wrote: > > Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor: > > > > Which of your other patches are still relevant? Thanks. > > > only this one. Thanks. Committed. Ian
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor:
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
Attached is the combined version of the two patches, only implementing the
variant with the tlhelp32 API.
Tested on x86 and x86_64 windows.
Kind regards,
Björn.
A friendly ping.
Thanks. Committed as follows.
Which of your other patches are still relevant? Thanks.
Ian
Hi,
only this one.
Kind regards,
Björn.From 55d0f312c0a9c4e2305d72fa2329b37937a02e44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sat, 6 Jan 2024 22:53:54 +0100
Subject: [PATCH 2/2] libbacktrace: Add loaded dlls after initialize
libbacktrace/Changelog:
* pecoff.c [HAVE_WINDOWS_H]:
(dll_notification_data): Added
(dll_notification_context): Added
(dll_notification): Added
(backtrace_initialize): Use LdrRegisterDllNotification to load
debug information of later loaded
dlls.
---
libbacktrace/pecoff.c | 106 ++
1 file changed, 106 insertions(+)
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index faa0be0b700..455a5c2191d 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -61,6 +61,34 @@ POSSIBILITY OF SUCH DAMAGE. */
#undef Module32Next
#endif
#endif
+
+#if defined(_ARM_)
+#define NTAPI
+#else
+#define NTAPI __stdcall
+#endif
+
+/* This is a simplified (but binary compatible) version of what Microsoft
+ defines in their documentation. */
+struct dll_notifcation_data
+{
+ ULONG reserved;
+ /* The name as UNICODE_STRING struct. */
+ PVOID full_dll_name;
+ PVOID base_dll_name;
+ PVOID dll_base;
+ ULONG size_of_image;
+};
+
+#define LDR_DLL_NOTIFICATION_REASON_LOADED 1
+
+typedef LONG NTSTATUS;
+typedef VOID CALLBACK (*LDR_DLL_NOTIFICATION)(ULONG,
+ struct dll_notifcation_data*,
+ PVOID);
+typedef NTSTATUS NTAPI (*LDR_REGISTER_FUNCTION)(ULONG,
+ LDR_DLL_NOTIFICATION, PVOID,
+ PVOID*);
#endif
/* Coff file header. */
@@ -911,6 +939,53 @@ coff_add (struct backtrace_state *state, int descriptor,
return 0;
}
+#ifdef HAVE_WINDOWS_H
+struct dll_notification_context
+{
+ struct backtrace_state *state;
+ backtrace_error_callback error_callback;
+ void *data;
+};
+
+static VOID CALLBACK
+dll_notification (ULONG reason,
+ struct dll_notifcation_data *notification_data,
+ PVOID context)
+{
+ char module_name[MAX_PATH];
+ int descriptor;
+ struct dll_notification_context* dll_context =
+(struct dll_notification_context*) context;
+ struct backtrace_state *state = dll_context->state;
+ void *data = dll_context->data;
+ backtrace_error_callback error_callback = dll_context->data;
+ fileline fileline;
+ int found_sym;
+ int found_dwarf;
+ HMODULE module_handle;
+
+ if (reason != LDR_DLL_NOTIFICATION_REASON_LOADED)
+return;
+
+ if (!GetModuleHandleExW (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
+ | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
+ (wchar_t*) notification_data->dll_base,
+ _handle))
+return;
+
+ if (!GetModuleFileNameA ((HMODULE) module_handle, module_name, MAX_PATH - 1))
+return;
+
+ descriptor = backtrace_open (module_name, error_callback, data, NULL);
+
+ if (descriptor < 0)
+return;
+
+ coff_add (state, descriptor, error_callback, data, , _sym,
+ _dwarf, (uintptr_t) module_handle);
+}
+#endif
+
/* Initialize the backtrace data we need from an ELF executable. At
the ELF level, all we need to do is find the debug info
sections. */
@@ -935,6 +1010,8 @@ backtrace_initialize (struct backtrace_state *state,
#endif
#ifdef HAVE_WINDOWS_H
+ HMODULE nt_dll_handle;
+
module_handle = (uintptr_t) GetModuleHandle (NULL);
#endif
@@ -981,6 +1058,35 @@ backtrace_initialize (struct backtrace_state *state,
}
#endif
+#ifdef HAVE_WINDOWS_H
+ nt_dll_handle = GetModuleHandleW (L"ntdll.dll");
+ if (nt_dll_handle)
+{
+ LDR_REGISTER_FUNCTION register_func;
+ const char register_name[] = "LdrRegisterDllNotification";
+ register_func = (void*) GetProcAddress (nt_dll_handle,
+ register_name);
+
+ if (register_func)
+ {
+ PVOID cookie;
+ struct dll_notification_context *context
+ = backtrace_alloc (state,
+ sizeof(struct dll_notification_context),
+ error_callback, data);
+
+ if (context)
+ {
+ context->state = state;
+ context->data = data;
+ context->error_callback = error_callback;
+
+ register_func (0, _notification, context, );
+
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor:
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
Attached is the combined version of the two patches, only implementing the
variant with the tlhelp32 API.
Tested on x86 and x86_64 windows.
Kind regards,
Björn.
A friendly ping.
Thanks. Committed as follows.
Which of your other patches are still relevant? Thanks.
Ian
Hi,
only this one.
Kind regards,
Björn.From 55d0f312c0a9c4e2305d72fa2329b37937a02e44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sat, 6 Jan 2024 22:53:54 +0100
Subject: [PATCH 2/2] libbacktrace: Add loaded dlls after initialize
libbacktrace/Changelog:
* pecoff.c [HAVE_WINDOWS_H]:
(dll_notification_data): Added
(dll_notification_context): Added
(dll_notification): Added
(backtrace_initialize): Use LdrRegisterDllNotification to load
debug information of later loaded
dlls.
---
libbacktrace/pecoff.c | 106 ++
1 file changed, 106 insertions(+)
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index faa0be0b700..455a5c2191d 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -61,6 +61,34 @@ POSSIBILITY OF SUCH DAMAGE. */
#undef Module32Next
#endif
#endif
+
+#if defined(_ARM_)
+#define NTAPI
+#else
+#define NTAPI __stdcall
+#endif
+
+/* This is a simplified (but binary compatible) version of what Microsoft
+ defines in their documentation. */
+struct dll_notifcation_data
+{
+ ULONG reserved;
+ /* The name as UNICODE_STRING struct. */
+ PVOID full_dll_name;
+ PVOID base_dll_name;
+ PVOID dll_base;
+ ULONG size_of_image;
+};
+
+#define LDR_DLL_NOTIFICATION_REASON_LOADED 1
+
+typedef LONG NTSTATUS;
+typedef VOID CALLBACK (*LDR_DLL_NOTIFICATION)(ULONG,
+ struct dll_notifcation_data*,
+ PVOID);
+typedef NTSTATUS NTAPI (*LDR_REGISTER_FUNCTION)(ULONG,
+ LDR_DLL_NOTIFICATION, PVOID,
+ PVOID*);
#endif
/* Coff file header. */
@@ -911,6 +939,53 @@ coff_add (struct backtrace_state *state, int descriptor,
return 0;
}
+#ifdef HAVE_WINDOWS_H
+struct dll_notification_context
+{
+ struct backtrace_state *state;
+ backtrace_error_callback error_callback;
+ void *data;
+};
+
+static VOID CALLBACK
+dll_notification (ULONG reason,
+ struct dll_notifcation_data *notification_data,
+ PVOID context)
+{
+ char module_name[MAX_PATH];
+ int descriptor;
+ struct dll_notification_context* dll_context =
+(struct dll_notification_context*) context;
+ struct backtrace_state *state = dll_context->state;
+ void *data = dll_context->data;
+ backtrace_error_callback error_callback = dll_context->data;
+ fileline fileline;
+ int found_sym;
+ int found_dwarf;
+ HMODULE module_handle;
+
+ if (reason != LDR_DLL_NOTIFICATION_REASON_LOADED)
+return;
+
+ if (!GetModuleHandleExW (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
+ | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
+ (wchar_t*) notification_data->dll_base,
+ _handle))
+return;
+
+ if (!GetModuleFileNameA ((HMODULE) module_handle, module_name, MAX_PATH - 1))
+return;
+
+ descriptor = backtrace_open (module_name, error_callback, data, NULL);
+
+ if (descriptor < 0)
+return;
+
+ coff_add (state, descriptor, error_callback, data, , _sym,
+ _dwarf, (uintptr_t) module_handle);
+}
+#endif
+
/* Initialize the backtrace data we need from an ELF executable. At
the ELF level, all we need to do is find the debug info
sections. */
@@ -935,6 +1010,8 @@ backtrace_initialize (struct backtrace_state *state,
#endif
#ifdef HAVE_WINDOWS_H
+ HMODULE nt_dll_handle;
+
module_handle = (uintptr_t) GetModuleHandle (NULL);
#endif
@@ -981,6 +1058,35 @@ backtrace_initialize (struct backtrace_state *state,
}
#endif
+#ifdef HAVE_WINDOWS_H
+ nt_dll_handle = GetModuleHandleW (L"ntdll.dll");
+ if (nt_dll_handle)
+{
+ LDR_REGISTER_FUNCTION register_func;
+ const char register_name[] = "LdrRegisterDllNotification";
+ register_func = (void*) GetProcAddress (nt_dll_handle,
+ register_name);
+
+ if (register_func)
+ {
+ PVOID cookie;
+ struct dll_notification_context *context
+ = backtrace_alloc (state,
+ sizeof(struct dll_notification_context),
+ error_callback, data);
+
+ if (context)
+ {
+ context->state = state;
+ context->data = data;
+ context->error_callback = error_callback;
+
+ register_func (0, _notification, context, );
+
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
>
> > Attached is the combined version of the two patches, only implementing the
> > variant with the tlhelp32 API.
> >
> > Tested on x86 and x86_64 windows.
> >
> > Kind regards,
> > Björn.
>
> A friendly ping.
Thanks. Committed as follows.
Which of your other patches are still relevant? Thanks.
Ian
942a9cf2a958113d2ab46f5b015c36e569abedcf
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 3e0075a2b79..59e9c415db8 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -380,6 +380,10 @@ if test "$have_loadquery" = "yes"; then
fi
AC_CHECK_HEADERS(windows.h)
+AC_CHECK_HEADERS(tlhelp32.h, [], [],
+[#ifdef HAVE_WINDOWS_H
+# include
+#endif])
# Check for the fcntl function.
if test -n "${with_target_subdir}"; then
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 9e437d810c7..4f267841178 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -49,6 +49,18 @@ POSSIBILITY OF SUCH DAMAGE. */
#endif
#include
+
+#ifdef HAVE_TLHELP32_H
+#include
+
+#ifdef UNICODE
+/* If UNICODE is defined, all the symbols are replaced by a macro to use the
+ wide variant. But we need the ansi variant, so undef the macros. */
+#undef MODULEENTRY32
+#undef Module32First
+#undef Module32Next
+#endif
+#endif
#endif
/* Coff file header. */
@@ -592,7 +604,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t addr,
static int
coff_add (struct backtrace_state *state, int descriptor,
backtrace_error_callback error_callback, void *data,
- fileline *fileline_fn, int *found_sym, int *found_dwarf)
+ fileline *fileline_fn, int *found_sym, int *found_dwarf,
+ uintptr_t module_handle ATTRIBUTE_UNUSED)
{
struct backtrace_view fhdr_view;
off_t fhdr_off;
@@ -870,12 +883,7 @@ coff_add (struct backtrace_state *state, int descriptor,
}
#ifdef HAVE_WINDOWS_H
- {
-uintptr_t module_handle;
-
-module_handle = (uintptr_t) GetModuleHandle (NULL);
-base_address = module_handle - image_base;
- }
+ base_address = module_handle - image_base;
#endif
if (!backtrace_dwarf_add (state, base_address, _sections,
@@ -917,12 +925,61 @@ backtrace_initialize (struct backtrace_state *state,
int found_sym;
int found_dwarf;
fileline coff_fileline_fn;
+ uintptr_t module_handle = 0;
+#ifdef HAVE_TLHELP32_H
+ fileline module_fileline_fn;
+ int module_found_sym;
+ HANDLE snapshot;
+#endif
+
+#ifdef HAVE_WINDOWS_H
+ module_handle = (uintptr_t) GetModuleHandle (NULL);
+#endif
ret = coff_add (state, descriptor, error_callback, data,
- _fileline_fn, _sym, _dwarf);
+ _fileline_fn, _sym, _dwarf, module_handle);
if (!ret)
return 0;
+#ifdef HAVE_TLHELP32_H
+ do
+{
+ snapshot = CreateToolhelp32Snapshot (TH32CS_SNAPMODULE, 0);
+}
+ while (snapshot == INVALID_HANDLE_VALUE
+&& GetLastError () == ERROR_BAD_LENGTH);
+
+ if (snapshot != INVALID_HANDLE_VALUE)
+{
+ MODULEENTRY32 entry;
+ BOOL ok;
+ entry.dwSize = sizeof (MODULEENTRY32);
+
+ for (ok = Module32First (snapshot, ); ok; ok = Module32Next
(snapshot, ))
+ {
+ if (strcmp (filename, entry.szExePath) == 0)
+ continue;
+
+ module_handle = (uintptr_t) entry.hModule;
+ if (module_handle == 0)
+ continue;
+
+ descriptor = backtrace_open (entry.szExePath, error_callback, data,
+ NULL);
+ if (descriptor < 0)
+ continue;
+
+ coff_add (state, descriptor, error_callback, data,
+ _fileline_fn, _found_sym, _dwarf,
+ module_handle);
+ if (module_found_sym)
+ found_sym = 1;
+ }
+
+ CloseHandle (snapshot);
+}
+#endif
+
if (!state->threaded)
{
if (found_sym)
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
>
> > Attached is the combined version of the two patches, only implementing the
> > variant with the tlhelp32 API.
> >
> > Tested on x86 and x86_64 windows.
> >
> > Kind regards,
> > Björn.
>
> A friendly ping.
Thanks. Committed as follows.
Which of your other patches are still relevant? Thanks.
Ian
942a9cf2a958113d2ab46f5b015c36e569abedcf
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 3e0075a2b79..59e9c415db8 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -380,6 +380,10 @@ if test "$have_loadquery" = "yes"; then
fi
AC_CHECK_HEADERS(windows.h)
+AC_CHECK_HEADERS(tlhelp32.h, [], [],
+[#ifdef HAVE_WINDOWS_H
+# include
+#endif])
# Check for the fcntl function.
if test -n "${with_target_subdir}"; then
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 9e437d810c7..4f267841178 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -49,6 +49,18 @@ POSSIBILITY OF SUCH DAMAGE. */
#endif
#include
+
+#ifdef HAVE_TLHELP32_H
+#include
+
+#ifdef UNICODE
+/* If UNICODE is defined, all the symbols are replaced by a macro to use the
+ wide variant. But we need the ansi variant, so undef the macros. */
+#undef MODULEENTRY32
+#undef Module32First
+#undef Module32Next
+#endif
+#endif
#endif
/* Coff file header. */
@@ -592,7 +604,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t addr,
static int
coff_add (struct backtrace_state *state, int descriptor,
backtrace_error_callback error_callback, void *data,
- fileline *fileline_fn, int *found_sym, int *found_dwarf)
+ fileline *fileline_fn, int *found_sym, int *found_dwarf,
+ uintptr_t module_handle ATTRIBUTE_UNUSED)
{
struct backtrace_view fhdr_view;
off_t fhdr_off;
@@ -870,12 +883,7 @@ coff_add (struct backtrace_state *state, int descriptor,
}
#ifdef HAVE_WINDOWS_H
- {
-uintptr_t module_handle;
-
-module_handle = (uintptr_t) GetModuleHandle (NULL);
-base_address = module_handle - image_base;
- }
+ base_address = module_handle - image_base;
#endif
if (!backtrace_dwarf_add (state, base_address, _sections,
@@ -917,12 +925,61 @@ backtrace_initialize (struct backtrace_state *state,
int found_sym;
int found_dwarf;
fileline coff_fileline_fn;
+ uintptr_t module_handle = 0;
+#ifdef HAVE_TLHELP32_H
+ fileline module_fileline_fn;
+ int module_found_sym;
+ HANDLE snapshot;
+#endif
+
+#ifdef HAVE_WINDOWS_H
+ module_handle = (uintptr_t) GetModuleHandle (NULL);
+#endif
ret = coff_add (state, descriptor, error_callback, data,
- _fileline_fn, _sym, _dwarf);
+ _fileline_fn, _sym, _dwarf, module_handle);
if (!ret)
return 0;
+#ifdef HAVE_TLHELP32_H
+ do
+{
+ snapshot = CreateToolhelp32Snapshot (TH32CS_SNAPMODULE, 0);
+}
+ while (snapshot == INVALID_HANDLE_VALUE
+&& GetLastError () == ERROR_BAD_LENGTH);
+
+ if (snapshot != INVALID_HANDLE_VALUE)
+{
+ MODULEENTRY32 entry;
+ BOOL ok;
+ entry.dwSize = sizeof (MODULEENTRY32);
+
+ for (ok = Module32First (snapshot, ); ok; ok = Module32Next
(snapshot, ))
+ {
+ if (strcmp (filename, entry.szExePath) == 0)
+ continue;
+
+ module_handle = (uintptr_t) entry.hModule;
+ if (module_handle == 0)
+ continue;
+
+ descriptor = backtrace_open (entry.szExePath, error_callback, data,
+ NULL);
+ if (descriptor < 0)
+ continue;
+
+ coff_add (state, descriptor, error_callback, data,
+ _fileline_fn, _found_sym, _dwarf,
+ module_handle);
+ if (module_found_sym)
+ found_sym = 1;
+ }
+
+ CloseHandle (snapshot);
+}
+#endif
+
if (!state->threaded)
{
if (found_sym)
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 15.03.2024 um 21:40 schrieb Björn Schäpers: Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor: On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. I noticed that under 64 bit libraries loaded with LoadLibrary were missing. EnumProcessModules stated the correct number of modules, but did not fill the the HMODULEs, but set them to 0. While trying to investigate I noticed if I do the very same thing from main (in C++) I even got fewer module HMODULEs. So I went a different way. This detects all libraries correctly, in 32 and 64 bit. The question is, if it should be a patch on top of the previous, or should they be merged, or even only this solution and drop the EnumProcessModules variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian This one needs the tlhelp32 header and its functions, which are (accoridng to the microsoft documentation) are only available since Windows XP rsp. Windows Server 2003. If that's no problem, and in my opinion it shouldn't be, then I can basically drop patch 4 and rebase this one. I don't see that as a problem. It seems like the patch will fall back cleanly on ancient Windows and simply fail to pick up other loaded DLLs. I think that is fine. I'll look for an updated patch. Thanks. Ian Attached is the combined version of the two patches, only implementing the variant with the tlhelp32 API. Tested on x86 and x86_64 windows. Kind regards, Björn. A friendly ping.
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 15.03.2024 um 21:40 schrieb Björn Schäpers: Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor: On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. I noticed that under 64 bit libraries loaded with LoadLibrary were missing. EnumProcessModules stated the correct number of modules, but did not fill the the HMODULEs, but set them to 0. While trying to investigate I noticed if I do the very same thing from main (in C++) I even got fewer module HMODULEs. So I went a different way. This detects all libraries correctly, in 32 and 64 bit. The question is, if it should be a patch on top of the previous, or should they be merged, or even only this solution and drop the EnumProcessModules variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian This one needs the tlhelp32 header and its functions, which are (accoridng to the microsoft documentation) are only available since Windows XP rsp. Windows Server 2003. If that's no problem, and in my opinion it shouldn't be, then I can basically drop patch 4 and rebase this one. I don't see that as a problem. It seems like the patch will fall back cleanly on ancient Windows and simply fail to pick up other loaded DLLs. I think that is fine. I'll look for an updated patch. Thanks. Ian Attached is the combined version of the two patches, only implementing the variant with the tlhelp32 API. Tested on x86 and x86_64 windows. Kind regards, Björn. A friendly ping.
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor:
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.
Thanks, but I don't want a patch that loops using goto statements.
Please rewrite to avoid that. It may be simpler to call a function.
Also starting with a module count of 1000 seems like a lot. Do
typical Windows programs load that many modules?
Ian
Rewritten using a function.
If that is commited, could you attribute that commit to me (--author="Björn
Schäpers ")?
Thanks and kind regards,
Björn.
I noticed that under 64 bit libraries loaded with LoadLibrary were missing.
EnumProcessModules stated the correct number of modules, but did not fill the
the HMODULEs, but set them to 0. While trying to investigate I noticed if I do
the very same thing from main (in C++) I even got fewer module HMODULEs.
So I went a different way. This detects all libraries correctly, in 32 and 64
bit. The question is, if it should be a patch on top of the previous, or should
they be merged, or even only this solution and drop the EnumProcessModules
variant?
Is there any reason to use both patches? Seems simpler to just use
this one if it works. Thanks.
Ian
This one needs the tlhelp32 header and its functions, which are (accoridng to
the microsoft documentation) are only available since Windows XP rsp. Windows
Server 2003.
If that's no problem, and in my opinion it shouldn't be, then I can basically
drop patch 4 and rebase this one.
I don't see that as a problem. It seems like the patch will fall back
cleanly on ancient Windows and simply fail to pick up other loaded
DLLs. I think that is fine. I'll look for an updated patch. Thanks.
Ian
Attached is the combined version of the two patches, only implementing the
variant with the tlhelp32 API.
Tested on x86 and x86_64 windows.
Kind regards,
Björn.From 33a6380feff66e32ef0f0d7cbad6fb55319f4e2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sun, 30 Apr 2023 23:54:32 +0200
Subject: [PATCH 1/2] libbacktrace: get debug information for loaded dlls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
libbacktrace/Changelog:
* configure.ac: Checked for tlhelp32.h
* configure: Regenerate.
* config.h.in: Regenerate.
* pecoff.c: Include if available.
(backtrace_initialize): Use tlhelp32 api for a snapshot to
detect loaded modules.
(coff_add): New argument for the module handle of the file,
to get the base address.
Signed-off-by: Björn Schäpers
---
libbacktrace/config.h.in | 3 +
libbacktrace/configure| 185 --
libbacktrace/configure.ac | 4 +
libbacktrace/pecoff.c | 74 +--
4 files changed, 171 insertions(+), 95 deletions(-)
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index ee2616335c7..9b8ab88ab63 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -101,6 +101,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_TYPES_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_TLHELP32_H
+
/* Define to 1 if you have the header file. */
#undef HAVE_UNISTD_H
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 7ade966b54d..ca52ee3bafb 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -1866,7 +1866,7 @@ else
#define $2 innocuous_$2
/* System header to define __stub macros and hopefully few prototypes,
-which can conflict with char $2 (); below.
+which can conflict with char $2 (void); below.
Prefer to if __STDC__ is defined, since
exists even on freestanding compilers. */
@@ -1884,7 +1884,7 @@ else
#ifdef __cplusplus
extern "C"
#endif
-char $2 ();
+char $2 (void);
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
@@ -1893,7 +1893,7 @@ choke me
#endif
int
-main ()
+main (void)
{
return $2 ();
;
@@ -1932,7 +1932,7 @@ else
/* end confdefs.h. */
$4
int
-main ()
+main (void)
{
if (sizeof ($2))
return 0;
@@
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor:
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.
Thanks, but I don't want a patch that loops using goto statements.
Please rewrite to avoid that. It may be simpler to call a function.
Also starting with a module count of 1000 seems like a lot. Do
typical Windows programs load that many modules?
Ian
Rewritten using a function.
If that is commited, could you attribute that commit to me (--author="Björn
Schäpers ")?
Thanks and kind regards,
Björn.
I noticed that under 64 bit libraries loaded with LoadLibrary were missing.
EnumProcessModules stated the correct number of modules, but did not fill the
the HMODULEs, but set them to 0. While trying to investigate I noticed if I do
the very same thing from main (in C++) I even got fewer module HMODULEs.
So I went a different way. This detects all libraries correctly, in 32 and 64
bit. The question is, if it should be a patch on top of the previous, or should
they be merged, or even only this solution and drop the EnumProcessModules
variant?
Is there any reason to use both patches? Seems simpler to just use
this one if it works. Thanks.
Ian
This one needs the tlhelp32 header and its functions, which are (accoridng to
the microsoft documentation) are only available since Windows XP rsp. Windows
Server 2003.
If that's no problem, and in my opinion it shouldn't be, then I can basically
drop patch 4 and rebase this one.
I don't see that as a problem. It seems like the patch will fall back
cleanly on ancient Windows and simply fail to pick up other loaded
DLLs. I think that is fine. I'll look for an updated patch. Thanks.
Ian
Attached is the combined version of the two patches, only implementing the
variant with the tlhelp32 API.
Tested on x86 and x86_64 windows.
Kind regards,
Björn.From 33a6380feff66e32ef0f0d7cbad6fb55319f4e2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sun, 30 Apr 2023 23:54:32 +0200
Subject: [PATCH 1/2] libbacktrace: get debug information for loaded dlls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
libbacktrace/Changelog:
* configure.ac: Checked for tlhelp32.h
* configure: Regenerate.
* config.h.in: Regenerate.
* pecoff.c: Include if available.
(backtrace_initialize): Use tlhelp32 api for a snapshot to
detect loaded modules.
(coff_add): New argument for the module handle of the file,
to get the base address.
Signed-off-by: Björn Schäpers
---
libbacktrace/config.h.in | 3 +
libbacktrace/configure| 185 --
libbacktrace/configure.ac | 4 +
libbacktrace/pecoff.c | 74 +--
4 files changed, 171 insertions(+), 95 deletions(-)
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index ee2616335c7..9b8ab88ab63 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -101,6 +101,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_TYPES_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_TLHELP32_H
+
/* Define to 1 if you have the header file. */
#undef HAVE_UNISTD_H
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 7ade966b54d..ca52ee3bafb 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -1866,7 +1866,7 @@ else
#define $2 innocuous_$2
/* System header to define __stub macros and hopefully few prototypes,
-which can conflict with char $2 (); below.
+which can conflict with char $2 (void); below.
Prefer to if __STDC__ is defined, since
exists even on freestanding compilers. */
@@ -1884,7 +1884,7 @@ else
#ifdef __cplusplus
extern "C"
#endif
-char $2 ();
+char $2 (void);
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
@@ -1893,7 +1893,7 @@ choke me
#endif
int
-main ()
+main (void)
{
return $2 ();
;
@@ -1932,7 +1932,7 @@ else
/* end confdefs.h. */
$4
int
-main ()
+main (void)
{
if (sizeof ($2))
return 0;
@@
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: > > Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: > > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > >> > >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > > > > From: Björn Schäpers > > > > Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > > that libraries loaded after the backtrace_initialize are not handled. > > But as far as I can see that's the same for elf. > > Thanks, but I don't want a patch that loops using goto statements. > Please rewrite to avoid that. It may be simpler to call a function. > > Also starting with a module count of 1000 seems like a lot. Do > typical Windows programs load that many modules? > > Ian > > > >>> > >>> Rewritten using a function. > >>> > >>> If that is commited, could you attribute that commit to me > >>> (--author="Björn > >>> Schäpers ")? > >>> > >>> Thanks and kind regards, > >>> Björn. > >> > >> I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > >> EnumProcessModules stated the correct number of modules, but did not fill > >> the > >> the HMODULEs, but set them to 0. While trying to investigate I noticed if > >> I do > >> the very same thing from main (in C++) I even got fewer module HMODULEs. > >> > >> So I went a different way. This detects all libraries correctly, in 32 and > >> 64 > >> bit. The question is, if it should be a patch on top of the previous, or > >> should > >> they be merged, or even only this solution and drop the EnumProcessModules > >> variant? > > > > Is there any reason to use both patches? Seems simpler to just use > > this one if it works. Thanks. > > > > Ian > > This one needs the tlhelp32 header and its functions, which are (accoridng to > the microsoft documentation) are only available since Windows XP rsp. Windows > Server 2003. > > If that's no problem, and in my opinion it shouldn't be, then I can basically > drop patch 4 and rebase this one. I don't see that as a problem. It seems like the patch will fall back cleanly on ancient Windows and simply fail to pick up other loaded DLLs. I think that is fine. I'll look for an updated patch. Thanks. Ian
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: > > Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: > > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > >> > >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > > > > From: Björn Schäpers > > > > Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > > that libraries loaded after the backtrace_initialize are not handled. > > But as far as I can see that's the same for elf. > > Thanks, but I don't want a patch that loops using goto statements. > Please rewrite to avoid that. It may be simpler to call a function. > > Also starting with a module count of 1000 seems like a lot. Do > typical Windows programs load that many modules? > > Ian > > > >>> > >>> Rewritten using a function. > >>> > >>> If that is commited, could you attribute that commit to me > >>> (--author="Björn > >>> Schäpers ")? > >>> > >>> Thanks and kind regards, > >>> Björn. > >> > >> I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > >> EnumProcessModules stated the correct number of modules, but did not fill > >> the > >> the HMODULEs, but set them to 0. While trying to investigate I noticed if > >> I do > >> the very same thing from main (in C++) I even got fewer module HMODULEs. > >> > >> So I went a different way. This detects all libraries correctly, in 32 and > >> 64 > >> bit. The question is, if it should be a patch on top of the previous, or > >> should > >> they be merged, or even only this solution and drop the EnumProcessModules > >> variant? > > > > Is there any reason to use both patches? Seems simpler to just use > > this one if it works. Thanks. > > > > Ian > > This one needs the tlhelp32 header and its functions, which are (accoridng to > the microsoft documentation) are only available since Windows XP rsp. Windows > Server 2003. > > If that's no problem, and in my opinion it shouldn't be, then I can basically > drop patch 4 and rebase this one. I don't see that as a problem. It seems like the patch will fall back cleanly on ancient Windows and simply fail to pick up other loaded DLLs. I think that is fine. I'll look for an updated patch. Thanks. Ian
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. I noticed that under 64 bit libraries loaded with LoadLibrary were missing. EnumProcessModules stated the correct number of modules, but did not fill the the HMODULEs, but set them to 0. While trying to investigate I noticed if I do the very same thing from main (in C++) I even got fewer module HMODULEs. So I went a different way. This detects all libraries correctly, in 32 and 64 bit. The question is, if it should be a patch on top of the previous, or should they be merged, or even only this solution and drop the EnumProcessModules variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian This one needs the tlhelp32 header and its functions, which are (accoridng to the microsoft documentation) are only available since Windows XP rsp. Windows Server 2003. If that's no problem, and in my opinion it shouldn't be, then I can basically drop patch 4 and rebase this one. Kind regards, Björn.
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. I noticed that under 64 bit libraries loaded with LoadLibrary were missing. EnumProcessModules stated the correct number of modules, but did not fill the the HMODULEs, but set them to 0. While trying to investigate I noticed if I do the very same thing from main (in C++) I even got fewer module HMODULEs. So I went a different way. This detects all libraries correctly, in 32 and 64 bit. The question is, if it should be a patch on top of the previous, or should they be merged, or even only this solution and drop the EnumProcessModules variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian This one needs the tlhelp32 header and its functions, which are (accoridng to the microsoft documentation) are only available since Windows XP rsp. Windows Server 2003. If that's no problem, and in my opinion it shouldn't be, then I can basically drop patch 4 and rebase this one. Kind regards, Björn.
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > > Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > >>> > >>> From: Björn Schäpers > >>> > >>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > >>> that libraries loaded after the backtrace_initialize are not handled. > >>> But as far as I can see that's the same for elf. > >> > >> Thanks, but I don't want a patch that loops using goto statements. > >> Please rewrite to avoid that. It may be simpler to call a function. > >> > >> Also starting with a module count of 1000 seems like a lot. Do > >> typical Windows programs load that many modules? > >> > >> Ian > >> > >> > > > > Rewritten using a function. > > > > If that is commited, could you attribute that commit to me (--author="Björn > > Schäpers ")? > > > > Thanks and kind regards, > > Björn. > > I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > EnumProcessModules stated the correct number of modules, but did not fill the > the HMODULEs, but set them to 0. While trying to investigate I noticed if I do > the very same thing from main (in C++) I even got fewer module HMODULEs. > > So I went a different way. This detects all libraries correctly, in 32 and 64 > bit. The question is, if it should be a patch on top of the previous, or > should > they be merged, or even only this solution and drop the EnumProcessModules > variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > > Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > >>> > >>> From: Björn Schäpers > >>> > >>> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > >>> that libraries loaded after the backtrace_initialize are not handled. > >>> But as far as I can see that's the same for elf. > >> > >> Thanks, but I don't want a patch that loops using goto statements. > >> Please rewrite to avoid that. It may be simpler to call a function. > >> > >> Also starting with a module count of 1000 seems like a lot. Do > >> typical Windows programs load that many modules? > >> > >> Ian > >> > >> > > > > Rewritten using a function. > > > > If that is commited, could you attribute that commit to me (--author="Björn > > Schäpers ")? > > > > Thanks and kind regards, > > Björn. > > I noticed that under 64 bit libraries loaded with LoadLibrary were missing. > EnumProcessModules stated the correct number of modules, but did not fill the > the HMODULEs, but set them to 0. While trying to investigate I noticed if I do > the very same thing from main (in C++) I even got fewer module HMODULEs. > > So I went a different way. This detects all libraries correctly, in 32 and 64 > bit. The question is, if it should be a patch on top of the previous, or > should > they be merged, or even only this solution and drop the EnumProcessModules > variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian
