GDB 7.99.91 MinGW compilation error in cli-script.c
Commit Message
On 05/19/2017 10:10 AM, Eli Zaretskii wrote:
>> Date: Wed, 17 May 2017 19:01:23 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> CC: simon.marchi@polymtl.ca, gdb-patches@sourceware.org
>>
>> I will probably post later a workaround patch for older versions,
>> but that's for master. I see no reason to delay the release or to
>> have the fix on the branch.
>
> Is the below OK? It's a bit ugly, and a small fix is needed even for
> the latest MinGW runtime.
Messing with libstdc++ internal macros and changing what libstdc++
defines is recipe for undefined behavior and trouble. I'd prefer
avoiding it if possible.
How about going back to the original gdb::to_string, implemented
in terms of stringstring:
https://sourceware.org/ml/gdb-patches/2016-10/msg00535.html
... with a tweak to only use if it the host compiler doesn't support
std::to_string, like the patchlet below. (It's functionally equivalent,
it's just that std::to_string is potentially cheaper.) We'd use
gdb::to_string instead of std::to_string until compilers that miss
std::to_string are phased out.
From bf3b8c9199965d15ddf8f0435fab6b6af3b08bda Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 19 May 2017 10:34:51 +0100
Subject: [PATCH] to_string
---
gdb/cli/cli-script.c | 2 +-
gdb/common/common-utils.h | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+), 1 deletion(-)
Comments
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Fri, 19 May 2017 10:48:57 +0100
>
> On 05/19/2017 10:10 AM, Eli Zaretskii wrote:
> >> Date: Wed, 17 May 2017 19:01:23 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> CC: simon.marchi@polymtl.ca, gdb-patches@sourceware.org
> >>
> >> I will probably post later a workaround patch for older versions,
> >> but that's for master. I see no reason to delay the release or to
> >> have the fix on the branch.
> >
> > Is the below OK? It's a bit ugly, and a small fix is needed even for
> > the latest MinGW runtime.
>
> Messing with libstdc++ internal macros and changing what libstdc++
> defines is recipe for undefined behavior and trouble. I'd prefer
> avoiding it if possible.
>
> How about going back to the original gdb::to_string, implemented
> in terms of stringstring:
>
> https://sourceware.org/ml/gdb-patches/2016-10/msg00535.html
>
> ... with a tweak to only use if it the host compiler doesn't support
> std::to_string, like the patchlet below.
Fine with me, but Someone(TM) should figure out what to use instead of
"#if 0".
On 05/19/2017 12:17 PM, Eli Zaretskii wrote:
> Fine with me, but Someone(TM) should figure out what to use instead of
> "#if 0".
>
Something around
__MINGW32__ / _GLIBCXX_USE_C99 / _GLIBCXX_HAVE_BROKEN_VSWPRINTF ?
Thanks,
Pedro Alves
@@ -806,7 +806,7 @@ user_args::insert_args (const char *line) const
if (p[4] == 'c')
{
- new_line += std::to_string (m_args.size ());
+ new_line += gdb::to_string (m_args.size ());
line = p + 5;
}
else
@@ -22,6 +22,7 @@
#include <string>
#include <vector>
+#include <sstream>
/* If possible, define FUNCTION_NAME, a macro containing the name of
the function being defined. Since this macro may not always be
@@ -63,6 +64,30 @@ int xsnprintf (char *str, size_t size, const char *format, ...)
std::string string_printf (const char* fmt, ...)
ATTRIBUTE_PRINTF (1, 2);
+/* Returns a string representation of VAL. Replacement for C++11
+ std::to_string on hosts that miss it. */
+
+namespace gdb {
+
+#if 0 // some check here
+
+template <class T>
+inline std::string
+to_string (const T &val)
+{
+ std::stringstream ss;
+
+ ss << val;
+ return ss.str ();
+}
+
+#else
+
+using std::to_string;
+
+#endif
+
+}
/* Make a copy of the string at PTR with LEN characters
(and add a null character at the end in the copy).
Uses malloc to get the space. Returns the address of the copy. */