[patch] fix remote host test failures in gdb.base/dup-sect.exp

[patch] fix remote host test failures in gdb.base/dup-sect.exp

[Sandra Loosemore]

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

The two tests at the end of gdb.base/dup-sect.exp have been failing in 
remote-host i686-mingw32 testing because the file containing the 
stripped debug information isn't being made available on the remote 
host.  I stole this fix from another test case that also uses 
gdb_gnu_strip_debug to produce separate debug info.

OK to commit?

-Sandra


2013-04-03  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite/

	* gdb.base/dup-sect.exp: Copy debug info file to remote host.


[-- Attachment #2: dup-sect.patch --]
[-- Type: text/x-patch, Size: 745 bytes --]

Index: gdb/testsuite/gdb.base/dup-sect.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/dup-sect.exp,v
retrieving revision 1.5
diff -u -p -r1.5 dup-sect.exp
--- gdb/testsuite/gdb.base/dup-sect.exp	1 Jan 2013 06:33:25 -0000	1.5
+++ gdb/testsuite/gdb.base/dup-sect.exp	4 Apr 2013 03:07:40 -0000
@@ -74,6 +74,13 @@ if {$result != 0} {
 }
 pass $test
 
+# gdb_gnu_strip_debug puts the debug info in $binfile.debug.  Make sure that
+# file is available on the remote host.
+set debugfile $binfile.debug
+if { [is_remote host] } {
+    set debugfile [remote_download host $debugfile]
+}
+
 clean_restart $executable
 
 gdb_test "p/d *(const char *) &var1" " = 1" "var1 after strip"

Re: [patch] fix remote host test failures in gdb.base/dup-sect.exp

[Pedro Alves]

On 04/04/2013 04:15 AM, Sandra Loosemore wrote:
> The two tests at the end of gdb.base/dup-sect.exp have been failing in remote-host
> i686-mingw32 testing because the file containing the stripped debug information isn't
> being made available on the remote host.  I stole this fix from another test case
> that also uses gdb_gnu_strip_debug to produce separate debug info.

Hmm, from which test?  I can't seem to find any that does this.
Could it be you've copied from a local change in some other test?

It looks like both this test and gdb_gnu_strip_debug run the
build machine's strip/objcopy.  How did that work?  Did you
happen to have i686-mingw32-strip / i686-mingw32-objcopy in the path
in the build machine?

-- 
Pedro Alves

Re: [patch] fix remote host test failures in gdb.base/dup-sect.exp

[Sandra Loosemore]

On 04/04/2013 05:09 AM, Pedro Alves wrote:
> On 04/04/2013 04:15 AM, Sandra Loosemore wrote:
>> The two tests at the end of gdb.base/dup-sect.exp have been failing in remote-host
>> i686-mingw32 testing because the file containing the stripped debug information isn't
>> being made available on the remote host.  I stole this fix from another test case
>> that also uses gdb_gnu_strip_debug to produce separate debug info.
>
> Hmm, from which test?  I can't seem to find any that does this.
> Could it be you've copied from a local change in some other test?
>
> It looks like both this test and gdb_gnu_strip_debug run the
> build machine's strip/objcopy.  How did that work?  Did you
> happen to have i686-mingw32-strip / i686-mingw32-objcopy in the path
> in the build machine?

Ah, you are right -- we have a local patch that hacks 
gdb_gnu_strip_debug to DTRT and adds the remote-host copy code to 
gdb.base/sepdebug.exp.

I'll withdraw this patch since we clearly need to merge it with the 
other unsubmitted changes.  Or, a simpler but less useful change would 
be do disable all the tests that depend on separate debug information in 
remote-host testing.

-Sandra

Re: [patch] fix remote host test failures in gdb.base/dup-sect.exp

[Pedro Alves]

On 04/04/2013 05:07 PM, Sandra Loosemore wrote:

> Ah, you are right -- we have a local patch that hacks gdb_gnu_strip_debug to DTRT and adds the remote-host copy code to gdb.base/sepdebug.exp.
> 
> I'll withdraw this patch since we clearly need to merge it with the other unsubmitted changes.  

Ack.

> Or, a simpler but less useful change would be do disable all the tests that depend on separate debug information in remote-host testing.

Yeah, it'll end up being throw away work given you already have the
right solution.  But I'll approve it if you send it.

-- 
Pedro Alves