Re: [patchv3 8/8] Tests for validate symbol file using build-id

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Mon, 03 Mar 2014 15:47:27 +0100, Pedro Alves wrote:
> you can have:
> 
>  GNU/Linux build x Windows host x Linux GDBserver target
> 
> Use of tcl's "file" procedures obviously break that scenario, as those
> run on "build".

OK, I forgot - putting there:
	if [is_remote host] {
	  untested "only local host is currently supported"
	  return -1
	}


> > I have added there:
> > 	if { [board_info target sockethost] != "localhost:" } {
> > 	  # The testcase below could be fixed for remote targets.
> > 	  untested "only gdbserver on localhost is supported (found [board_info target sockethost])"
> > 	  return -1
> > 	}
> 
> Not sure.  I think I'd rather leave this out, so that someone else
> doing remote target testing might perhaps get motivated to address it.

I would expect that one can fix all testcases that are skipped during remote
mode.  OK, I have removed the code above.


> Might it be just a gdb_load_shlibs call is missing?  Can't easily tell
> from just a skim over the test.
> 
> As is, I think the test is being skipped with
> --target_board=native-extended-remote.exp, due to
> the !is_remote check.

I do not know "native-extended-remote.exp" but I guess it is "localhost" with
"target extended-remote".  The test is really skipped while it does not have
to be.

I find it good enough that it runs in one of the basic test runs (=gdbserver
in non-extended mode).  It could run in more modes but then it would be best
to:

 * really fix the remote mode, even for remote different-filesystems
   and just run it in any remote mode
 * implement build-id reporting also for linux-nat
 * implement build-id reporting also for core files
 * tons of other extensions

But primarily this whole validation functionality is outside of the scope of
my business goal and it was included only as a convenience to the original
submitter.  Getting deeper and deeper to the functionality outside of my
goal is not too practical.  The suggested extensions can be perfectly made
incrementally later.


> Sounds like gdb_is_target_remote from qtro.exp would be a better fit, or
> IOW, time to move that to gdb.exp ?

I do not find it great to put more work to workarounds of the current testcase
bug.  With more work one can already fix the real remote different-filesystem
bug of the testcase.


> > Someone on gdb-patches was fixing testcases from
> > time to time to run on real non-localhost remote configurations.  When such
> > configuration is already setup it is easier to fix all such skipped testcases.
> 
> FWIW, we have "--host_board=local-remote-host" nowadays so anyone
> can easily try, but I don't know how well that works.

It does not help in this case as it still runs on the same filesystem.
For example a forgotten remote upload/download will not be noticed.


Thanks,
Jan