[PATCH] long long for printf on MinGW

[PATCH] long long for printf on MinGW

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

Hi,

Windows/MinGW printf does support printing of long long types, but it 
does not do using %lld etc.

This patch converts %ll (or %...ll) to %I64 as required by Windows.

GDB printf still won't accept I64 as input, but then this is not 
standard compliant so I don't think it really should.

:ADDPATCH printcmd.c:

Andrew Stubbs

[-- Attachment #2: printf.patch --]
[-- Type: text/plain, Size: 1673 bytes --]

2006-10-11  Andrew Stubbs  <andrew.stubbs@st.com>

	* printcmd.c (printf_command): Convert %lld to %I64d on MinGW.

Index: src/gdb/printcmd.c
===================================================================
--- src.orig/gdb/printcmd.c	2006-07-17 23:15:55.000000000 +0100
+++ src/gdb/printcmd.c	2006-10-11 11:28:29.000000000 +0100
@@ -1967,8 +1967,24 @@ printf_command (char *arg, int from_tty)
 		   *f);
 
 	  f++;
-	  strncpy (current_substring, last_arg, f - last_arg);
-	  current_substring += f - last_arg;
+#if defined (__MINGW32__)
+	  /* Windows' printf does support long long, but not the usual way.
+	     Convert %lld to %I64d.  */
+	  if (lcount > 1)
+	    {
+	      int length_before_ll = f - last_arg - 1 - lcount;
+	      strncpy (current_substring, last_arg, length_before_ll);
+	      strcpy (current_substring + length_before_ll, "I64");
+	      current_substring[length_before_ll + 3] =
+		last_arg[length_before_ll + lcount];
+	      current_substring += length_before_ll + 4;
+	    }
+	  else
+#endif
+	    {
+	      strncpy (current_substring, last_arg, f - last_arg);
+	      current_substring += f - last_arg;
+	    }
 	  *current_substring++ = '\0';
 	  last_arg = f;
 	  argclass[nargs_wanted++] = this_argclass;
@@ -2056,7 +2072,8 @@ printf_command (char *arg, int from_tty)
 	    error (_("long double not supported in printf"));
 #endif
 	  case long_long_arg:
-#if defined (CC_HAS_LONG_LONG) && defined (PRINTF_HAS_LONG_LONG)
+#if defined (CC_HAS_LONG_LONG) && (defined (PRINTF_HAS_LONG_LONG) \
+				   || defined (__MINGW32__))
 	    {
 	      long long val = value_as_long (val_args[i]);
 	      printf_filtered (current_substring, val);

Re: [PATCH] long long for printf on MinGW

[Daniel Jacobowitz]

On Wed, Oct 11, 2006 at 11:57:49AM +0100, Andrew STUBBS wrote:
> Hi,
> 
> Windows/MinGW printf does support printing of long long types, but it 
> does not do using %lld etc.
> 
> This patch converts %ll (or %...ll) to %I64 as required by Windows.
> 
> GDB printf still won't accept I64 as input, but then this is not 
> standard compliant so I don't think it really should.
> 
> :ADDPATCH printcmd.c:
> 
> Andrew Stubbs

I don't much like #ifdef __MINGW32__, but I'm not sure what else to do
about it... I suppose we could autoconf for inttypes.h and check for
PRIx64 starting with 'I', but that's no better.

Could you at least do something like this?

#if defined(__MINGW32__)
# define USE_PRINTF_I64 1
# define PRINTF_HAS_LONG_LONG
#else
# define USE_PRINTF_I64 0
#endif

    if (lcount > 1 && USE_PRINTF_I64)

The GCC folks learned a hard lesson that conditionally compiled code is
a maintenance burden all its own.

Thanks in advance.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

Daniel Jacobowitz wrote:
> Could you at least do something like this?

Ok, how about the attached. I believe I have done it just how you asked.

Andrew Stubbs

[-- Attachment #2: printf.patch --]
[-- Type: text/plain, Size: 1660 bytes --]

2006-10-11  Andrew Stubbs  <andrew.stubbs@st.com>

	* printcmd.c: Define USE_PRINTF_I64 and PRINTF_HAS_LONG_LONG on MinGW.
	(printf_command): Convert %lld to %I64d when USE_PRINTF_I64 set.

Index: src/gdb/printcmd.c
===================================================================
--- src.orig/gdb/printcmd.c	2006-07-17 23:15:55.000000000 +0100
+++ src/gdb/printcmd.c	2006-10-11 14:47:57.000000000 +0100
@@ -48,6 +48,13 @@
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
 
+#if defined(__MINGW32__)
+# define USE_PRINTF_I64 1
+# define PRINTF_HAS_LONG_LONG
+#else
+# define USE_PRINTF_I64 0
+#endif
+
 extern int asm_demangle;	/* Whether to demangle syms in asm printouts */
 extern int addressprint;	/* Whether to print hex addresses in HLL " */
 
@@ -1967,8 +1974,23 @@ printf_command (char *arg, int from_tty)
 		   *f);
 
 	  f++;
-	  strncpy (current_substring, last_arg, f - last_arg);
-	  current_substring += f - last_arg;
+
+	  if (lcount > 1 && USE_PRINTF_I64)
+	    {
+	      /* Windows' printf does support long long, but not the usual way.
+		 Convert %lld to %I64d.  */
+	      int length_before_ll = f - last_arg - 1 - lcount;
+	      strncpy (current_substring, last_arg, length_before_ll);
+	      strcpy (current_substring + length_before_ll, "I64");
+	      current_substring[length_before_ll + 3] =
+		last_arg[length_before_ll + lcount];
+	      current_substring += length_before_ll + 4;
+	    }
+	  else
+	    {
+	      strncpy (current_substring, last_arg, f - last_arg);
+	      current_substring += f - last_arg;
+	    }
 	  *current_substring++ = '\0';
 	  last_arg = f;
 	  argclass[nargs_wanted++] = this_argclass;

Re: [PATCH] long long for printf on MinGW

[Daniel Jacobowitz]

On Wed, Oct 11, 2006 at 04:12:40PM +0100, Andrew STUBBS wrote:
> 2006-10-11  Andrew Stubbs  <andrew.stubbs@st.com>
> 
> 	* printcmd.c: Define USE_PRINTF_I64 and PRINTF_HAS_LONG_LONG on MinGW.
> 	(printf_command): Convert %lld to %I64d when USE_PRINTF_I64 set.

I'm somewhat willing to approve this patch.  Note this is the revised
one from
  http://sourceware.org/ml/gdb-patches/2006-10/msg00117.html

I had ambitious plans involving making printf work on target types.
But they aren't going to come through any time soon.

However, for host types we could import the printf (vsprintf-posix)
module from gnulib, then always assume PRINTF_HAS_LONG_LONG as long as
HAVE_LONG_LONG_INT.  I did the work of adding gnulib modules already.
So maybe this is a better option.  What do you think?

> +	      /* Windows' printf does support long long, but not the usual way.
> +		 Convert %lld to %I64d.  */
> +	      int length_before_ll = f - last_arg - 1 - lcount;
> +	      strncpy (current_substring, last_arg, length_before_ll);
> +	      strcpy (current_substring + length_before_ll, "I64");
> +	      current_substring[length_before_ll + 3] =
> +		last_arg[length_before_ll + lcount];
> +	      current_substring += length_before_ll + 4;

You've got enough buffer space to do this but I had to think about it
a couple times to work out why :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> However, for host types we could import the printf (vsprintf-posix)
> module from gnulib, then always assume PRINTF_HAS_LONG_LONG as long as
> HAVE_LONG_LONG_INT.  I did the work of adding gnulib modules already.
> So maybe this is a better option.  What do you think?

I'm not sufficiently familiar with gnulib to know what gotchas there 
might be, but I imagine it would at least solve the problem of different 
behaviour on different hosts, given the same target.

That said, selfishly speaking, it's overkill for _my_ problem, and I 
don't know of any other problems in this area - apart from hosts that 
just plain don't have long long, and you seem to suggest that gnulib 
won't solve that?

>> +	      /* Windows' printf does support long long, but not the usual way.
>> +		 Convert %lld to %I64d.  */
>> +	      int length_before_ll = f - last_arg - 1 - lcount;
>> +	      strncpy (current_substring, last_arg, length_before_ll);
>> +	      strcpy (current_substring + length_before_ll, "I64");
>> +	      current_substring[length_before_ll + 3] =
>> +		last_arg[length_before_ll + lcount];
>> +	      current_substring += length_before_ll + 4;
> 
> You've got enough buffer space to do this but I had to think about it
> a couple times to work out why :-)

Unless I'm mistaken, the code reserves enough space for every character 
to be in it's own nul-terminated substring, but since the minimum length 
%-spec is two characters, that's impossible. In this specific example, 
there would be 8 bytes reserved for the string "%lld" - enough for 
"%\0l\0l\0d\0", but "%I64d\0" only uses 6.

Re: [PATCH] long long for printf on MinGW

[Daniel Jacobowitz]

On Wed, Apr 23, 2008 at 10:28:38AM +0100, Andrew STUBBS wrote:
> That said, selfishly speaking, it's overkill for _my_ problem, and I  
> don't know of any other problems in this area - apart from hosts that  
> just plain don't have long long, and you seem to suggest that gnulib  
> won't solve that?

You can't pass a long long by C varargs if your compiler doesn't
support it, and GDB won't do anything sensible anyway - LONGEST
will be a long.

> Unless I'm mistaken, the code reserves enough space for every character  
> to be in it's own nul-terminated substring, but since the minimum length  
> %-spec is two characters, that's impossible. In this specific example,  
> there would be 8 bytes reserved for the string "%lld" - enough for  
> "%\0l\0l\0d\0", but "%I64d\0" only uses 6.

Right.

Go ahead with the patch.  We can rip it out if we switch to gnulib's
printf.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

Daniel Jacobowitz wrote:
> Go ahead with the patch.  We can rip it out if we switch to gnulib's
> printf.

Committed.

I've attached the final verion. It's only the patch offsets that have 
changed since the last patch posted.

Thanks

Andrew

[-- Attachment #2: updated-printf.patch --]
[-- Type: text/plain, Size: 1727 bytes --]

2008-04-23  Andrew Stubbs  <andrew.stubbs@st.com>

	* printcmd.c: Define USE_PRINTF_I64 and PRINTF_HAS_LONG_LONG on MinGW.
	(printf_command): Convert %lld to %I64d when USE_PRINTF_I64 set.

Index: gdb/printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.117
diff -u -p -r1.117 printcmd.c
--- gdb/printcmd.c	30 Jan 2008 19:19:51 -0000	1.117
+++ gdb/printcmd.c	23 Apr 2008 12:05:33 -0000
@@ -47,6 +47,13 @@
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
 
+#if defined(__MINGW32__)
+# define USE_PRINTF_I64 1
+# define PRINTF_HAS_LONG_LONG
+#else
+# define USE_PRINTF_I64 0
+#endif
+
 extern int asm_demangle;	/* Whether to demangle syms in asm printouts */
 extern int addressprint;	/* Whether to print hex addresses in HLL " */
 
@@ -2009,8 +2016,23 @@ printf_command (char *arg, int from_tty)
 		   *f);
 
 	  f++;
-	  strncpy (current_substring, last_arg, f - last_arg);
-	  current_substring += f - last_arg;
+
+	  if (lcount > 1 && USE_PRINTF_I64)
+	    {
+	      /* Windows' printf does support long long, but not the usual way.
+		 Convert %lld to %I64d.  */
+	      int length_before_ll = f - last_arg - 1 - lcount;
+	      strncpy (current_substring, last_arg, length_before_ll);
+	      strcpy (current_substring + length_before_ll, "I64");
+	      current_substring[length_before_ll + 3] =
+		last_arg[length_before_ll + lcount];
+	      current_substring += length_before_ll + 4;
+	    }
+	  else
+	    {
+	      strncpy (current_substring, last_arg, f - last_arg);
+	      current_substring += f - last_arg;
+	    }
 	  *current_substring++ = '\0';
 	  last_arg = f;
 	  argclass[nargs_wanted++] = this_argclass;

Re: [PATCH] long long for printf on MinGW

[Mark Kettenis]

>  Hi,
>
>  Windows/MinGW printf does support printing of long long types, but it
>  does not do using %lld etc.
>
>  This patch converts %ll (or %...ll) to %I64 as required by Windows.

What!  Seven years after ISO C99 was ratified, Microsoft still ships a libc
that doesn't support %ll?

Sigh, I don't see why we need to treat MINGW special here.  We should
probably
just print an error if PRINTF_HAS_LONG_LONG isn't defined.

Actually I think the way we support size modifiers in gdb's printf are
completely broken.  Do they refer to the host types, or the target types?

Re: [PATCH] long long for printf on MinGW

[Daniel Jacobowitz]

On Wed, Oct 11, 2006 at 10:28:21PM +0200, Mark Kettenis wrote:
> Actually I think the way we support size modifiers in gdb's printf are
> completely broken.  Do they refer to the host types, or the target types?

Good question: which do you want them to refer to?

I have already rewritten this file pretty much from scratch once in
2006, so I'm understandably not too eager to do it again :-)  But if we
must, then we must.

I do not see any clear way to support target types while still taking
advantage of the host printf, however.  Perhaps I should go back to my
prototype patch for line wrapping, which would let us import bits of
"gnulib".  Which has a nice thorough printf format string parser
that we might be able to reuse.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS]

Mark Kettenis wrote:
>>  Hi,
>>
>>  Windows/MinGW printf does support printing of long long types, but it
>>  does not do using %lld etc.
>>
>>  This patch converts %ll (or %...ll) to %I64 as required by Windows.
> 
> What!  Seven years after ISO C99 was ratified, Microsoft still ships a libc
> that doesn't support %ll?

I'm still using Win2K, so I don't think you can count all of those seven 
years. So are many of our customers and, no doubt, other users. The MSDN 
I have is dated 2002.

> Sigh, I don't see why we need to treat MINGW special here.  We should
> probably
> just print an error if PRINTF_HAS_LONG_LONG isn't defined.

That's what it does, and what I don't want it to do. Why shouldn't I be 
able to see long long values, as supported by the target, just because I 
happen to use a Windows host. It isn't a difficult fixup and doesn't 
break or even affect any other host.

Please don't point out some other way of displaying the value, that 
isn't the point and is just proof that it ought to work.

> Actually I think the way we support size modifiers in gdb's printf are
> completely broken.  Do they refer to the host types, or the target types?

'Completely' broken or not, they work for most peoples' needs, but in 
this respect they don't work for Windows users' needs.

Andrew

Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS]

Mark Kettenis wrote:
> I'm not sure it "ought to work".  The host printf(3) doesn't support
> "%lld", so why should gdb support it?

How about 'because it can'?

> If your answer is "because the target printf(3) supports it", then
> think again.  By using the host printf(3) like we now do, the gdb
> printf prints types with widths as they are on the host, and not as
> they are on the target.

I'm rather more interested in the usability of the debugger than 
niceties of implementation.

When a customer reports that a feature doesn't work on a platform, I 
don't like to tell them that it shouldn't work unless I have a really 
good reason. If Windows only had a 62 bit printf (or something else 
ridiculous) then that might qualify, but I can't find a reason in this case.

Andrew