[RFA] ARI fix: remove 6 last %p occurences

[RFA] ARI fix: remove 6 last %p occurences

[Pierre Muller]

This second patch would remove "%p" in 
printf-like function.

 I apparently missed ia64-tdep.c completely on my previous patch,
do know why.

  The two last changes in symmisc.c were postponed 
in my first patch because I had a question:
> I left a few cases out, where
> the %p value was not a simple pointer
> but a arithmetic operation,
> I don't know the rules for C,
> is an addition of a pointer and a integer always of type pointer?

But nobody answered :(
Thus I suppose that, indeed, for all C compilers
there will never be any typecast problems here...


Anyone is welcome to raise up here to say the contrary...

Is this OK?

Pierre Muller
GDB pascal language maintainer
and ARI-fixer
 

2009-04-19  Pierre Muller  <muller.u-strasbg.fr>

	ARI fix: remove "%p".
	* ia64-tdep.c (ia64_frame_this_id): Use host_address_to_string
function.
	(ia64_sigtramp_frame_this_id): Ditto.
	(ia64_libunwind_frame_this_id): Ditto.
	(ia64_libunwind_sigtramp_frame_this_id): Ditto.
	* symmisc.c (maintenance_info_psymtabs): Ditto.


Index: ia64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ia64-tdep.c,v
retrieving revision 1.189
diff -u -p -r1.189 ia64-tdep.c
--- ia64-tdep.c	22 Feb 2009 01:02:17 -0000	1.189
+++ ia64-tdep.c	18 Apr 2009 22:41:39 -0000
@@ -1717,10 +1717,11 @@ ia64_frame_this_id (struct frame_info *t
     (*this_id) = frame_id_build_special (cache->base, cache->pc,
cache->bsp);
   if (gdbarch_debug >= 1)
     fprintf_unfiltered (gdb_stdlog,
-			"regular frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %p\n",
+			"regular frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %s\n",
 			paddr_nz (this_id->code_addr), 
 			paddr_nz (this_id->stack_addr), 
-			paddr_nz (cache->bsp), this_frame);
+			paddr_nz (cache->bsp),
+			host_address_to_string (this_frame));
 }
 
 static struct value *
@@ -2072,10 +2073,11 @@ ia64_sigtramp_frame_this_id (struct fram
                                        cache->bsp);
   if (gdbarch_debug >= 1)
     fprintf_unfiltered (gdb_stdlog,
-			"sigtramp frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %p\n",
+			"sigtramp frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %s\n",
 			paddr_nz (this_id->code_addr), 
 			paddr_nz (this_id->stack_addr), 
-			paddr_nz (cache->bsp), this_frame);
+			paddr_nz (cache->bsp),
+			host_address_to_string (this_frame));
 }
 
 static struct value *
@@ -2733,9 +2735,10 @@ ia64_libunwind_frame_this_id (struct fra
 
   if (gdbarch_debug >= 1)
     fprintf_unfiltered (gdb_stdlog,
-			"libunwind frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %p\n",
+			"libunwind frame id: code 0x%s, stack 0x%s, special
0x%s, this_frame %s\n",
 			paddr_nz (id.code_addr), paddr_nz (id.stack_addr), 
-			paddr_nz (bsp), this_frame);
+			paddr_nz (bsp),
+			host_address_to_string (this_frame));
 }
 
 static struct value *
@@ -2858,9 +2861,10 @@ ia64_libunwind_sigtramp_frame_this_id (s
 
   if (gdbarch_debug >= 1)
     fprintf_unfiltered (gdb_stdlog,
-			"libunwind sigtramp frame id: code 0x%s, stack 0x%s,
special 0x%s, this_frame %p\n",
+			"libunwind sigtramp frame id: code 0x%s, stack 0x%s,
special 0x%s, this_frame %s\n",
 			paddr_nz (id.code_addr), paddr_nz (id.stack_addr), 
-			paddr_nz (bsp), this_frame);
+			paddr_nz (bsp),
+			host_address_to_string (this_frame));
 }
 
 static struct value *
Index: symmisc.c
===================================================================
RCS file: /cvs/src/src/gdb/symmisc.c,v
retrieving revision 1.61
diff -u -p -r1.61 symmisc.c
--- symmisc.c	17 Apr 2009 15:44:28 -0000	1.61
+++ symmisc.c	18 Apr 2009 22:41:39 -0000
@@ -1027,8 +1027,9 @@ maintenance_info_psymtabs (char *regexp,
 	      printf_filtered ("    globals ");
 	      if (psymtab->n_global_syms)
 		{
-		  printf_filtered ("(* (struct partial_symbol **) %p @
%d)\n",
-				   (psymtab->objfile->global_psymbols.list
+		  printf_filtered ("(* (struct partial_symbol **) %s @
%d)\n",
+				   host_address_to_string (
+				    psymtab->objfile->global_psymbols.list
 				    + psymtab->globals_offset),
 				   psymtab->n_global_syms);
 		}
@@ -1037,8 +1038,9 @@ maintenance_info_psymtabs (char *regexp,
 	      printf_filtered ("    statics ");
 	      if (psymtab->n_static_syms)
 		{
-		  printf_filtered ("(* (struct partial_symbol **) %p @
%d)\n",
-				   (psymtab->objfile->static_psymbols.list
+		  printf_filtered ("(* (struct partial_symbol **) %s @
%d)\n",
+				   host_address_to_string (
+				    psymtab->objfile->static_psymbols.list
 				    + psymtab->statics_offset),
 				   psymtab->n_static_syms);
 		}

Re: [RFA] ARI fix: remove 6 last %p occurences

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <muller@ics.u-strasbg.fr> writes:

Pierre>   The two last changes in symmisc.c were postponed 
Pierre> in my first patch because I had a question:
[...]
>> I don't know the rules for C,
>> is an addition of a pointer and a integer always of type pointer?
Pierre> But nobody answered :(

Sorry about that.  Yes, in C, the addition of a pointer and an integer
always has pointer type.

Pierre> Is this OK?

Yes, thanks.

Pierre> +				   host_address_to_string (
Pierre> +				    psymtab->objfile->global_psymbols.list

The formatting here looks a bit weird.  There aren't many good
choices, but usually I just choose to let the line wrap rather than
splitting after the "(".

Tom

RE: [RFA] ARI fix: remove 6 last %p occurences

[Pierre Muller]

Thanks for the approval.

I checked the patch in,
but left the two lines together, even if they
do wrap as they are too long in symmisc.c


Pierre Muller
Pascal language support maintainer for GDB




> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : Tuesday, April 21, 2009 2:06 AM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA] ARI fix: remove 6 last %p occurences
> 
> >>>>> "Pierre" == Pierre Muller <muller@ics.u-strasbg.fr> writes:
> 
> Pierre>   The two last changes in symmisc.c were postponed
> Pierre> in my first patch because I had a question:
> [...]
> >> I don't know the rules for C,
> >> is an addition of a pointer and a integer always of type pointer?
> Pierre> But nobody answered :(
> 
> Sorry about that.  Yes, in C, the addition of a pointer and an integer
> always has pointer type.
> 
> Pierre> Is this OK?
> 
> Yes, thanks.
> 
> Pierre> +				   host_address_to_string (
> Pierre> +				    psymtab->objfile-
> >global_psymbols.list
> 
> The formatting here looks a bit weird.  There aren't many good
> choices, but usually I just choose to let the line wrap rather than
> splitting after the "(".
> 
> Tom