Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* gdb 7.6: Fix info mem command for 32 bits host/64 bits target
@ 2013-06-26 15:10 Udma Catalin-Dan-B32721
  2013-06-26 16:07 ` Pedro Alves
  0 siblings, 1 reply; 8+ messages in thread
From: Udma Catalin-Dan-B32721 @ 2013-06-26 15:10 UTC (permalink / raw)
  To: gdb-patches

Hi,
I found an issue with the "info mem" command when running gdb on 32 bits host for 64 bits target architecture.
"info mem" command truncates the target address to 32 bits, like in the example below:

    (gdb) set architecture powerpc:common64
    The target architecture is assumed to be powerpc:common64
    (gdb) mem 0x100000000 0x200000000 rw
    (gdb) info mem
    Using user-defined memory regions.
    Num Enb Low Addr           High Addr          Attrs
    1   y   0x0000000000000000 0x0000000000000000 rw nocache

Please find below the proposed patch. Please let me know your comments.

Regards,
Catalin


Subject: [PATCHH] Fix info mem command for 32 bits host/64 bits target

When running gdb on 32 bits host for 64 bits target, info mem command
truncates the target address to 32 bits, like in the example below
	(gdb) set architecture powerpc:common64 
	(gdb) mem 0x100000000 0x200000000 rw
	(gdb) info mem
	1   y  	0x0000000000000000 0x0000000000000000 rw nocache 

Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
---
--- gdb/memattr.c.orig	2013-06-27 17:28:20.000000000 +0300
+++ gdb/memattr.c	2013-06-27 17:29:16.000000000 +0300
@@ -447,9 +447,9 @@
 		       m->number,
 		       m->enabled_p ? 'y' : 'n');
       if (gdbarch_addr_bit (target_gdbarch ()) <= 32)
-	tmp = hex_string_custom ((unsigned long) m->lo, 8);
+	tmp = hex_string_custom ((LONGEST) m->lo, 8);
       else
-	tmp = hex_string_custom ((unsigned long) m->lo, 16);
+	tmp = hex_string_custom ( (LONGEST) m->lo, 16);
       
       printf_filtered ("%s ", tmp);
 
@@ -458,14 +458,14 @@
 	  if (m->hi == 0)
 	    tmp = "0x100000000";
 	  else
-	    tmp = hex_string_custom ((unsigned long) m->hi, 8);
+	    tmp = hex_string_custom ((LONGEST) m->hi, 8);
 	}
       else
 	{
 	  if (m->hi == 0)
 	    tmp = "0x10000000000000000";
 	  else
-	    tmp = hex_string_custom ((unsigned long) m->hi, 16);
+	    tmp = hex_string_custom ((LONGEST) m->hi, 16);
 	}
 
       printf_filtered ("%s ", tmp);



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 15:10 gdb 7.6: Fix info mem command for 32 bits host/64 bits target Udma Catalin-Dan-B32721
@ 2013-06-26 16:07 ` Pedro Alves
  2013-06-26 16:11   ` Pedro Alves
                     ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Pedro Alves @ 2013-06-26 16:07 UTC (permalink / raw)
  To: Udma Catalin-Dan-B32721; +Cc: gdb-patches

On 06/26/2013 04:07 PM, Udma Catalin-Dan-B32721 wrote:
> Hi,
> I found an issue with the "info mem" command when running gdb on 32 bits host for 64 bits target architecture.
> "info mem" command truncates the target address to 32 bits, like in the example below:
> 
>     (gdb) set architecture powerpc:common64
>     The target architecture is assumed to be powerpc:common64
>     (gdb) mem 0x100000000 0x200000000 rw
>     (gdb) info mem
>     Using user-defined memory regions.
>     Num Enb Low Addr           High Addr          Attrs
>     1   y   0x0000000000000000 0x0000000000000000 rw nocache
> 
> Please find below the proposed patch. Please let me know your comments.

Thanks!  The (LONGEST) casts look unnecessary, as
hex_string_custom already takes LONGEST.

This needs a ChangeLog entry.  See
<http://sourceware.org/gdb/wiki/ContributionChecklist>.  Could
you send one?

In order to backport to the 7.6 branch, we'll need a bugzilla entry
filed, reporting the bug.  Could you do that?  That will be used
to record the bug fix in <http://sourceware.org/gdb/wiki/GDB_7.6_Release>.

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 16:07 ` Pedro Alves
@ 2013-06-26 16:11   ` Pedro Alves
  2013-06-26 16:17     ` Pedro Alves
  2013-06-26 17:11     ` Tom Tromey
  2013-06-26 16:20   ` Udma Catalin-Dan-B32721
  2013-06-27  8:42   ` Udma Catalin-Dan-B32721
  2 siblings, 2 replies; 8+ messages in thread
From: Pedro Alves @ 2013-06-26 16:11 UTC (permalink / raw)
  To: gdb-patches; +Cc: Udma Catalin-Dan-B32721

BTW,

$ grep hex_string_custom * | grep long

finds:

breakpoint.c:  /* The longest string possibly returned by hex_string_custom
breakpoint.c:  strcpy (astr1, hex_string_custom ((unsigned long) from_addr, 8));
breakpoint.c:  strcpy (astr2, hex_string_custom ((unsigned long) to_addr, 8));

Those casts are likewise bogus:

static void
breakpoint_adjustment_warning (CORE_ADDR from_addr, CORE_ADDR to_addr,
                               int bnum, int have_bnum)
{
  /* The longest string possibly returned by hex_string_custom
     is 50 chars.  These must be at least that big for safety.  */
  char astr1[64];
  char astr2[64];

  strcpy (astr1, hex_string_custom ((unsigned long) from_addr, 8));
  strcpy (astr2, hex_string_custom ((unsigned long) to_addr, 8));
  if (have_bnum)
    warning (_("Breakpoint %d address previously adjusted from %s to %s."),
             bnum, astr1, astr2);
  else
    warning (_("Breakpoint address adjusted from %s to %s."), astr1, astr2);
}

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 16:11   ` Pedro Alves
@ 2013-06-26 16:17     ` Pedro Alves
  2013-06-26 17:11     ` Tom Tromey
  1 sibling, 0 replies; 8+ messages in thread
From: Pedro Alves @ 2013-06-26 16:17 UTC (permalink / raw)
  To: gdb-patches; +Cc: Udma Catalin-Dan-B32721

On 06/26/2013 05:07 PM, Pedro Alves wrote:
> BTW,
> 
> $ grep hex_string_custom * | grep long
> 
> finds:
> 
> breakpoint.c:  /* The longest string possibly returned by hex_string_custom
> breakpoint.c:  strcpy (astr1, hex_string_custom ((unsigned long) from_addr, 8));
> breakpoint.c:  strcpy (astr2, hex_string_custom ((unsigned long) to_addr, 8));
> 
> Those casts are likewise bogus:

Filed <http://sourceware.org/bugzilla/show_bug.cgi?id=15683>.

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 16:07 ` Pedro Alves
  2013-06-26 16:11   ` Pedro Alves
@ 2013-06-26 16:20   ` Udma Catalin-Dan-B32721
  2013-06-27  8:42   ` Udma Catalin-Dan-B32721
  2 siblings, 0 replies; 8+ messages in thread
From: Udma Catalin-Dan-B32721 @ 2013-06-26 16:20 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

> Thanks!  The (LONGEST) casts look unnecessary, as
> hex_string_custom already takes LONGEST.
> 
> This needs a ChangeLog entry.  See
> <http://sourceware.org/gdb/wiki/ContributionChecklist>.  Could
> you send one?
> 
> In order to backport to the 7.6 branch, we'll need a bugzilla entry
> filed, reporting the bug.  Could you do that?  That will be used
> to record the bug fix in
> <http://sourceware.org/gdb/wiki/GDB_7.6_Release>.
> 
> --
> Pedro Alves
[CU] Sure, I'll update the patch and the ChangeLog. And I'll open the bug for this.
[CU] Catalin


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 16:11   ` Pedro Alves
  2013-06-26 16:17     ` Pedro Alves
@ 2013-06-26 17:11     ` Tom Tromey
  1 sibling, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2013-06-26 17:11 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches, Udma Catalin-Dan-B32721

Pedro> static void
Pedro> breakpoint_adjustment_warning (CORE_ADDR from_addr, CORE_ADDR to_addr,
Pedro>                                int bnum, int have_bnum)
Pedro> {
Pedro>   /* The longest string possibly returned by hex_string_custom
Pedro>      is 50 chars.  These must be at least that big for safety.  */
Pedro>   char astr1[64];
Pedro>   char astr2[64];

Pedro>   strcpy (astr1, hex_string_custom ((unsigned long) from_addr, 8));
Pedro>   strcpy (astr2, hex_string_custom ((unsigned long) to_addr, 8));

These strcpy calls are also bogus.
hex_string_custom uses the "cell" mechanism, so this code can assume
that these calls don't interfere.

Tom


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-26 16:07 ` Pedro Alves
  2013-06-26 16:11   ` Pedro Alves
  2013-06-26 16:20   ` Udma Catalin-Dan-B32721
@ 2013-06-27  8:42   ` Udma Catalin-Dan-B32721
  2013-06-27  8:44     ` Pedro Alves
  2 siblings, 1 reply; 8+ messages in thread
From: Udma Catalin-Dan-B32721 @ 2013-06-27  8:42 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

Hi,
Re-sending the patch including: bug entry, changeLog and the patch.

Regards,
Catalin


Bug entry:
http://sourceware.org/bugzilla/show_bug.cgi?id=15684 


gdb/ChangeLog:

2013-06-26  Catalin Udma  <catalin.udma@freescale.com>

	* memattr.c (mem_info_command): Fix info mem command
	for 32 bits host/64 bits target by removing incorrect cast


Patch:

Subject: [PATCH] Fix info mem command for 32 bits host/64 bits target

When running gdb on 32 bits host for 64 bits target, info mem command
truncates the target address to 32 bits, like in the example below
	(gdb) set architecture powerpc:common64 
	(gdb) mem 0x100000000 0x200000000 rw
	(gdb) info mem
	1   y  	0x0000000000000000 0x0000000000000000 rw nocache 

Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
---
--- gdb/memattr.c.orig	2013-06-27 17:28:20.000000000 +0300
+++ gdb/memattr.c	2013-06-27 17:29:16.000000000 +0300
@@ -447,9 +447,9 @@
 		       m->number,
 		       m->enabled_p ? 'y' : 'n');
       if (gdbarch_addr_bit (target_gdbarch ()) <= 32)
-	tmp = hex_string_custom ((unsigned long) m->lo, 8);
+	tmp = hex_string_custom (m->lo, 8);
       else
-	tmp = hex_string_custom ((unsigned long) m->lo, 16);
+	tmp = hex_string_custom (m->lo, 16);
       
       printf_filtered ("%s ", tmp);
 
@@ -458,14 +458,14 @@
 	  if (m->hi == 0)
 	    tmp = "0x100000000";
 	  else
-	    tmp = hex_string_custom ((unsigned long) m->hi, 8);
+	    tmp = hex_string_custom (m->hi, 8);
 	}
       else
 	{
 	  if (m->hi == 0)
 	    tmp = "0x10000000000000000";
 	  else
-	    tmp = hex_string_custom ((unsigned long) m->hi, 16);
+	    tmp = hex_string_custom (m->hi, 16);
 	}
 
       printf_filtered ("%s ", tmp);





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gdb 7.6: Fix info mem command for 32 bits host/64 bits target
  2013-06-27  8:42   ` Udma Catalin-Dan-B32721
@ 2013-06-27  8:44     ` Pedro Alves
  0 siblings, 0 replies; 8+ messages in thread
From: Pedro Alves @ 2013-06-27  8:44 UTC (permalink / raw)
  To: Udma Catalin-Dan-B32721; +Cc: gdb-patches

On 06/27/2013 09:19 AM, Udma Catalin-Dan-B32721 wrote:
> Hi,
> Re-sending the patch including: bug entry, changeLog and the patch.
> 
> Regards,
> Catalin
> 
> 
> Bug entry:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15684 
> 
> 
> gdb/ChangeLog:
> 
> 2013-06-26  Catalin Udma  <catalin.udma@freescale.com>
> 
> 	* memattr.c (mem_info_command): Fix info mem command
> 	for 32 bits host/64 bits target by removing incorrect cast

ChangeLog entries say "what" changed.  It also includes the PR
associated with the patch.  I.e., write:

2013-06-26  Catalin Udma  <catalin.udma@freescale.com>

	PR gdb/15684
 	* memattr.c (mem_info_command): Remove "unsigned long" casts.

OK with that change.

Thanks,
-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-06-27  8:42 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-26 15:10 gdb 7.6: Fix info mem command for 32 bits host/64 bits target Udma Catalin-Dan-B32721
2013-06-26 16:07 ` Pedro Alves
2013-06-26 16:11   ` Pedro Alves
2013-06-26 16:17     ` Pedro Alves
2013-06-26 17:11     ` Tom Tromey
2013-06-26 16:20   ` Udma Catalin-Dan-B32721
2013-06-27  8:42   ` Udma Catalin-Dan-B32721
2013-06-27  8:44     ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox