Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration shou
Am 29.07.2024 um 19:58 schrieb Eli Zaretskii:
From: Ian Lance Taylor
Date: Mon, 29 Jul 2024 09:46:46 -0700
Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
Date: Tue, 9 Jan 2024
From: Björn Schäpers
libstdc++-v3/Changelog
* acinclude.m4 (GLIBCXX_ENABLE_BACKTACE): Add check for
tlhelp32.h, matching libbacktrace.
* configure: Regenerate.
* config.h.in: Regenerate.
Signed-off-by: Björn Schäpers
---
libstdc++-v3/acinclude.m4 | 4
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
Am 24.03.2024 um 22:34 schrieb Björn Schäpers:
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration should be moved into
ops-common.h, since then we could use stat
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
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration should be moved into
ops-common.h, since then we could use stat_type and also use that in the
commonly used fun
Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
Date: Tue, 9 Jan 2024 21:02:44 +0100
Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers
Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
In that case, you an call either GetModuleHandeExA or
GetModuleHandeExW, the
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
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
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
Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
Date: Sun, 7 Jan 2024 17:07:06 +0100
Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers
That was about GetModuleHandle, not about GetModuleHandleEx. For the
latter, all Windows versions that support it also
Am 07.01.2024 um 15:46 schrieb Eli Zaretskii:
[I re-added the other addressees, as I don' think you meant to make
this discussion private between the two of us.]
Yeah, that was a mistake.
Date: Sun, 7 Jan 2024 12:58:29 +0100
From: Björn Schäpers
Am 07.01.2024 um 07:50 schrie
Am 04.01.2024 um 23:33 schrieb Björn Schäpers:
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
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
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
8 +0100
Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
Why is this part needed?
Otherwise, LGTM, thanks. (But I'm don't have the approval rights, so
please wait for Ian to chime in.)
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
---
libbacktrace/pecoff.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libbacktrace/pecoff.
Hi,
this is what I'm using with GCC 12 and 13 on my windows machines, rebased onto
the current HEAD.
Kind regards,
Björn.
Am 06.02.2023 um 01:22 schrieb Ian Lance Taylor:
On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers wrote:
Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
On Tue, J
Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
wrote:
From: Ian Lance Taylor
Date: Tue, 24 Jan 2023 09:58:10 -0800
Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
I'd rather that the patch look like the appended
Am 24.01.2023 um 17:52 schrieb Eli Zaretskii:
From: Ian Lance Taylor
Date: Tue, 24 Jan 2023 06:35:21 -0800
Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.
The limit of 3
Am 20.01.2023 um 23:25 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:54 AM Björn Schäpers wrote:
From: Björn Schäpers
It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a
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.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* pecoff.c (
From: Björn Schäpers
This is actually needed so that libstdc++'s implementation
to be able to work on windows.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* configure.ac: Add a check for windows.h.
* configure, config.h.in: Regenerate.
* filelin
From: Björn Schäpers
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
From: Björn Schäpers
It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a following patch.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* dwarf.c: changed vari
From: Björn Schäpers
One could add (), these are not part of __name. One could also try to
check upfront if __cxa_demangle should be called at all.
-- >8 --
Tested on i686-w64-mingw32.
__cxa_demangle is only to demangle C++ names, for all C functions,
extern "C" functions, and i
From: Björn Schäpers
One could add (), these are not part of __name. One could also try to
check upfront if __cxa_demangle should be called at all.
-- >8 --
Tested on i686-w64-mingw32.
__cxa_demangle is only to demangle C++ names, for all C functions,
extern "C" functions, and i
From: Björn Schäpers
One could add (), these are not part of __name. One could also try to
check upfront if __cxa_demangle should be called at all.
-- >8 --
Tested on i686-w64-mingw32.
__cxa_demangle is only to demangle C++ names, for all C functions,
extern "C" functions, and i
From: Björn Schäpers
libstdc++-v3/Changelog
* acinclude.m4: Add check for windows.h.
* acinclude.m4: Add pecoff as FORMAT_FILE.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/libbacktrace/Makefile.am: Regenerate.
* src/libbacktrace
From: Björn Schäpers
This is actually needed so that libstdc++'s implementation
to be able to work on windows.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* configure.ac: Add a check for windows.h.
* configure, config.h.in: Regenerate.
* filelin
From: Björn Schäpers
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
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.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* pecoff.c (
From: Björn Schäpers
It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a following patch.
Tested on x86_64-linux and i686-w64-mingw32.
-- >8 --
* dwarf.c: changed vari
to be tested.
Björn.
Am 30.11.2022 um 07:04 schrieb François Dumont:
Good catch, then we also need this patch.
I still need to test it thought, just to make sure it compiles. Unless you have
a nice way to force call to the error callback ?
François
On 29/11/22 22:41, Björn Schäpers wrote:
Weitergeleitete Nachricht
Betreff: [PATCH] libstdc++: Add error handler for
Datum: Tue, 29 Nov 2022 22:41:07 +0100
Von: Björn Schäpers
An: gcc-patc...@gc.gnu.org, libstd...@gcc.gnu.org
From: Björn Schäpers
Not providing an error handler results in a nullpointer
36 matches
Mail list logo