Re: [PATCH 1/2] GDB test suite: Add helper for locating core files

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Wed, Oct 11 2017, Kevin Buettner wrote:

> On Mon, 09 Oct 2017 20:46:21 +0200
> Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
>
>> > Instead, several warnings are now printed instead:
>> >
>> >     WARNING: Can not generate core dump on remote target.  
>> 
>> These warnings are newly introduced by the patch.
>
> Yes, I saw that.
>
>> They are meant to
>> improve diagnostics when someone attempts to run the tests on a "real"
>> remote target.  I wanted to clearly document the fact that this is
>> unsupported (and always was).  Also, by documenting this restriction,
>> maybe someone feels encouraged to lift it ;-)
>
> In the distant past, I used to run the testsuite against resource
> constrained linux machines often of a different architecture from the
> host I was running the tests from.  These machines would run gdbserver
> built for that architecture.

OK, in that scenario, core file test cases would need to be roughly
executed in four steps:

(1) Build executable.
(2) Run executable on the remote machine.
(3) Transfer core dump to the local host.
(4) Start GDB on the local host.

AFAIK, steps (2) and (3) have not been implemented for the GDB test
suite so far.

> Now, I don't recall whether corefile support in the testsuite actually
> worked for those targets, but it at least seems possible due to the
> various invocations of remote_exec which are present (prior to your
> patch).

Fairly unlikely.  See, for instance, the beginning of corefile.exp:

  # are we on a target board
  if ![isnative] then {
      return
  }

A check like this appears in all core dump test cases.

Also note that the core_find command in gdb.exp uses expect's "system"
command for invoking the executable:

  catch "system \"(cd ${coredir}; ulimit -c unlimited; ${binfile} ${arg}; true) >/dev/null 2>&1\""

Which means that this command line will be executed on the local machine
and will fail in a remote setup.

But you're right that there were remote_exec invocations; mostly for
file handling such as:

  remote_exec build "mv $i $destcore"

  remote_exec build "mv $corefile $destcore"

  remote_exec build "rmdir $coredir"

TBH, I don't quite understand their intention.  In a native remote
setup, "build" is the remote machine.  Moving the core file around there
doesn't make it appear on the local machine.  And in a cross remote
setup, "build" is the local machine, whereas the core dump should be
generated on the remote machine.  So I think these commands only work if
host == build == target.  Since I found this too misleading, I replaced
them by local commands.

> Do you think you could restore those calls to remote_exec in your
> patch?  Or do you know for a fact that they do not work?

I'm pretty sure they don't.  Thus I wanted to document this restriction
more clearly.

--
Andreas