gdb.base/dump.exp: Force the correct endianness

gdb.base/dump.exp: Force the correct endianness

[Maciej W. Rozycki]

Hello,

 Testcases in gdb.base/dump.exp use binary formats that do not carry 
endianness information.  This causes failures if gdb supports both 
endiannesses, but the original binary used by the script is of the 
non-default one.

 The following fix has been successfully tested for mipsisa32-sde-elf, 
with the mips-sim-sde32/-EB and mips-sim-sde32/-EL target boards.  Gdb 
defaults to the big endianness in this configuration, so with the latter 
board dumps of arrays from SREC and hex formats are currently seen 
endian-reversed.

2007-07-24  Maciej W. Rozycki  <macro@mips.com>

	* gdb.base/dump.exp: Force the correct endianness for binary
	formats not carrying this information.

 OK to apply?

  Maciej

gdb-dump-endian.diff
Index: gdb/src/gdb/testsuite/gdb.base/dump.exp
===================================================================
--- gdb.orig/src/gdb/testsuite/gdb.base/dump.exp	2007-01-09 17:59:11.000000000 +0000
+++ gdb/src/gdb/testsuite/gdb.base/dump.exp	2007-07-24 17:25:17.000000000 +0100
@@ -34,6 +34,7 @@
 set options  {debug}
 
 set is64bitonly "no"
+set endian "auto"
 
 if [istarget "alpha*-*-*"] then {
     # SREC etc cannot handle 64-bit addresses.  Force the test
@@ -70,6 +71,19 @@
     return -1
 }
 
+# Get the endianness for the later use with endianless formats.
+
+send_gdb "show endian\n"
+gdb_expect {
+    -re ".* (big|little) endian.*$gdb_prompt $" { 
+	set endian $expect_out(1,string) 
+	pass "endianness: $endian"
+    }
+    default {
+	fail "(timeout) getting target endianness"
+    }
+}
+
 # Now generate some dump files.
 
 proc make_dump_file { command msg } {
@@ -190,6 +204,18 @@
 gdb_start
 gdb_file_cmd ${binfile}
 
+# Now fix the endianness at the correct state.
+
+send_gdb "set endian $endian\n"
+gdb_expect {
+    -re ".* (big|little) endian.*$gdb_prompt $" { 
+	pass "setting $endian endianness"
+    }
+    default {
+	fail "(timeout) setting $endian endianness"
+    }
+}
+
 # Reload saved values one by one, and compare.
 
 if { ![string compare $array_val \

Re: gdb.base/dump.exp: Force the correct endianness

[Jim Blandy]

"Maciej W. Rozycki" <macro@mips.com> writes:
>  Testcases in gdb.base/dump.exp use binary formats that do not carry 
> endianness information.  This causes failures if gdb supports both 
> endiannesses, but the original binary used by the script is of the 
> non-default one.
>
>  The following fix has been successfully tested for mipsisa32-sde-elf, 
> with the mips-sim-sde32/-EB and mips-sim-sde32/-EL target boards.  Gdb 
> defaults to the big endianness in this configuration, so with the latter 
> board dumps of arrays from SREC and hex formats are currently seen 
> endian-reversed.
>
> 2007-07-24  Maciej W. Rozycki  <macro@mips.com>
>
> 	* gdb.base/dump.exp: Force the correct endianness for binary
> 	formats not carrying this information.
>
>  OK to apply?

This looks reasonable --- please apply it, if you've also tested it on
some desktop-like system.

Also, you should go ahead and add yourself at the proper point in the
"Write After Approval" section of gdb/MAINTAINERS, as a separate
commit, with a ChangeLog entry.

Re: gdb.base/dump.exp: Force the correct endianness

[Maciej W. Rozycki]

On Wed, 25 Jul 2007, Jim Blandy wrote:

> > 2007-07-24  Maciej W. Rozycki  <macro@mips.com>
> >
> >	* gdb.base/dump.exp: Force the correct endianness for binary
> >	formats not carrying this information.
> >
> >  OK to apply?
>
> This looks reasonable --- please apply it, if you've also tested it on
> some desktop-like system.

 Well, the mips-unknown-linux-gnu host works fine natively.  I hope it
qualifies as a desktop-like system (the machine itself comes in a desktop
case if that helps).

 The "show/set endian" commands are supported universally even if the
currently chosen architecture comes in a single endianness only.  But in
that case gdb should still accept a command to force the endianness to one
already set automatically -- if that failed, it would qualify as a bug
IMO, so perhaps the change adds a useful test case as a side effect.

> Also, you should go ahead and add yourself at the proper point in the
> "Write After Approval" section of gdb/MAINTAINERS, as a separate
> commit, with a ChangeLog entry.

 Yeah, probably -- it has been too long already since I have got my
assignment sorted out.  Would it be OK to provide my both e-mail addresses
(which generally differentiate between sponsored and volunteer work) or
should I just pick one?

  Maciej