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

  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(-)
  

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.
  

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.
  

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.
  

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.