diff mbox

Make gdb.server/connect-with-no-symbol-file.exp more robust

Message ID 1460746522-6703-1-git-send-email-lgustavo@codesourcery.com
State New
Headers show

Commit Message

Luis Machado April 15, 2016, 6:55 p.m. UTC
Yao noticed failing tests with the remote-gdbserver-on-localhost board file.

Investigating further i noticed the test, as is,  may delete the original symbol
files, causing failures to occur.

I went ahead and adjusted the test so it properly restores the state of the
files with every iteration and also moved the required commands to functions.

Last, i adjusted the "detach" pattern because extended remote does not
completely disconnect from GDB, so it doesn't show the last piece of text.

I get full passes with the following board files:

native-gdbserver.exp
native-extended-gdbserver.exp
remote-gdbserver-on-localhost.exp

Unfortunately i see FAIL's (4) with both stdio-based gdbserver boards because,
obviously, the launching of gdbserver and issuing of the "target remote"
command happen at the same time. Thus, no time to delete or make the symbol
file inacessible.

Any suggestions? Should we restrict this test to non-stdio boards?

gdb/testsuite/ChangeLog:

2016-04-15  Luis Machado  <lgustavo@codesourcery.com>

	gdb.server/connect-with-no-symbol-file.exp (delete_files): New
	function.
	(restore_files_from_backup): New function.
	(make_inaccessible): New function.
	(connect_no_symbol_file): Adjust detachment test pattern.
	Call helper functions.
---
 .../gdb.server/connect-with-no-symbol-file.exp     | 32 ++++++++++++++++++----
 1 file changed, 27 insertions(+), 5 deletions(-)

Comments

Yao Qi April 18, 2016, 11:03 a.m. UTC | #1
Luis Machado <lgustavo@codesourcery.com> writes:

Hi Luis,

> Investigating further i noticed the test, as is,  may delete the original symbol
> files, causing failures to occur.
>
> I went ahead and adjusted the test so it properly restores the state of the
> files with every iteration and also moved the required commands to functions.
>

I think we shouldn't remove any generated files during the test, so that
the fails can be manually reproduced.  Instead of deleting the file, can't
we start gdb with files of different names?  Say, when $action is
"delete", we can just set binfile to
connect-with-no-symbol-file-nonexist.  When $action is "permission",
copy connect-with-no-symbol-file to
connect-with-no-symbol-file-not_permitted, change its permission, and
set binfile to it.  What do you think?

> Unfortunately i see FAIL's (4) with both stdio-based gdbserver boards because,
> obviously, the launching of gdbserver and issuing of the "target remote"
> command happen at the same time. Thus, no time to delete or make the symbol
> file inacessible.

I don't know much about stdio gdbserver, so have no comment on it.
Luis Machado April 18, 2016, 3:56 p.m. UTC | #2
On 04/18/2016 06:03 AM, Yao Qi wrote:
> Luis Machado <lgustavo@codesourcery.com> writes:
>
> Hi Luis,
>
>> Investigating further i noticed the test, as is,  may delete the original symbol
>> files, causing failures to occur.
>>
>> I went ahead and adjusted the test so it properly restores the state of the
>> files with every iteration and also moved the required commands to functions.
>>
>
> I think we shouldn't remove any generated files during the test, so that
> the fails can be manually reproduced.  Instead of deleting the file, can't
> we start gdb with files of different names?  Say, when $action is

The idea of the test is to start GDB with no symbol files. It will 
either try to load a symbol file that doesn't exist (because we deleted 
it on the host) or will get an error from GDBserver saying the file is 
not accessible

> "delete", we can just set binfile to
> connect-with-no-symbol-file-nonexist.  When $action is "permission",
> copy connect-with-no-symbol-file to
> connect-with-no-symbol-file-not_permitted, change its permission, and
> set binfile to it.  What do you think?

If the problem is making a copy of the files, wouldn't it be easier to 
do a backup of the file with tweaked permissions? We already have the 
original file backup that we use to restore state.

Tweaking the binfile may cause the test to be a little convoluted since 
we deal with real remote targets and localhost-remote targets. In the 
latter, manipulating the file on the target also manipulates the file on 
the host.
Yao Qi April 18, 2016, 4:21 p.m. UTC | #3
Luis Machado <lgustavo@codesourcery.com> writes:

> If the problem is making a copy of the files, wouldn't it be easier to
> do a backup of the file with tweaked permissions? We already have the
> original file backup that we use to restore state.

That is fine by me.
Luis Machado May 17, 2016, 5:58 p.m. UTC | #4
On 04/18/2016 11:21 AM, Yao Qi wrote:
> Luis Machado <lgustavo@codesourcery.com> writes:
>
>> If the problem is making a copy of the files, wouldn't it be easier to
>> do a backup of the file with tweaked permissions? We already have the
>> original file backup that we use to restore state.
>
> That is fine by me.
>

Sorry for the delay. If nobody has comments on the stdio-based testing, 
i'll send a final version of this patch.
diff mbox

Patch

diff --git a/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp b/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
index f99e1af..6657399 100644
--- a/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
+++ b/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
@@ -33,6 +33,27 @@  if { [prepare_for_testing $testfile.exp $testfile $srcfile debug] } {
     return -1
 }
 
+# Delete FILE in both the host and the target.
+#
+proc delete_files { file } {
+  remote_file host delete $file
+  remote_file target delete $file
+}
+
+# Restore FILE in both the host and the target from FILE.bak.
+#
+proc restore_files_from_backup { file } {
+    gdb_remote_download host $file.bak $file
+    gdb_remote_download target $file.bak $file
+}
+
+# Make FILE inaccessible in both the host and the target.
+#
+proc make_inaccessible { file } {
+    remote_exec host "chmod 000 $file"
+    remote_exec target "chmod 000 $file"
+}
+
 # Test connecting GDB to GDBserver without loading a symbol file.
 #
 # SYSROOT is the desired sysroot string
@@ -45,8 +66,9 @@  proc connect_no_symbol_file { sysroot action } {
     global binfile
 
     with_test_prefix "setup" {
-	# Copy the symbol file to the target.
-	gdb_remote_download target $binfile.bak $binfile 
+	# Restore the files to the initial state.
+	delete_files $binfile
+	restore_files_from_backup $binfile
 
 	# Make sure we're disconnected, in case we're testing with an
 	# extended-remote board, therefore already connected.
@@ -70,9 +92,9 @@  proc connect_no_symbol_file { sysroot action } {
 
 	# Perform test actions to the symbol file on the target.
 	if { $action == "delete" } then {
-	  remote_file target delete $binfile
+	    delete_files $binfile
 	} elseif { $action == "permission" } {
-	  remote_spawn target "chmod 000 $binfile"
+	    make_inaccessible $binfile
 	}
        
 	# Connect to GDBserver.
@@ -82,7 +104,7 @@  proc connect_no_symbol_file { sysroot action } {
     # Check if GDB succeeded connecting to GDBserver by attempting to detach
     # from the process.
     gdb_test "detach" \
-	".*Detaching from program: , process.*Ending remote debugging.*" \
+	".*Detaching from program: , process \[0-9\]+\[^\r\n\]*.*" \
 	"connection to GDBserver succeeded"
 }