]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run
authorSimon Marchi <simon.marchi@polymtl.ca>
Thu, 10 Jun 2021 14:47:39 +0000 (10:47 -0400)
committerSimon Marchi <simon.marchi@polymtl.ca>
Thu, 5 Aug 2021 16:24:44 +0000 (12:24 -0400)
commit52e0e32b34e503630e124cd60365a6d3ec5b1181
treea1cfe92607fcbbba782d3983be6b2756eba0111e
parentb765e92113f2a6d13f6cfe09b3a074a6e0dec19f
gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run

When running this test with the native-extended-gdbserver, we get:

    main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
    19   while (! should_exit)
    The program being debugged has been started already.
    Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt
    y
    Don't know how to run.  Try "help target".
    (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main

This test tests using both "-p <pid>" and "-ex start" on the command line,
making sure that we first attach and then run.

Normally, after that "y", we should see the program running again.
However, a particuliarity of the native-extended-gdbserver is that it
uses "set auto-connect-native-target off" on the command line.  The full
GDB command line is:

    ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \
          -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \
  -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start

The attach succeeds.  I guess it is done before "set
auto-connect-native-target off", or it somehow bypasses it.  When the
"start" is executed, the native target is unpushed, while killing the
existing process, but not re-pushed, due to "set
auto-connect-native-target off".  So we get that "Don't know how to run"
message.

Really, I think it's a case of the test doing things incompatible with
the board, I think it should just be skipped.  And as we can see with
the current code, there were some attempts at doing this, just using the
wrong checks:

 - isnative: this is a dejagnu proc which checks if the target board has
   the same triplet as the build machine.  In the case of
   native-extended-gdbserver, it does.
 - is_remote target: this checks whether the target board is remote, as
   in executing on a different machin.  native-extended-gdbserver is not
   remote.

Since the --pid option specifically attaches to a process using the
native target, change the test to use gdb_is_target_native instead.

gdb/testsuite/ChangeLog:

* gdb.base/attach.exp (test_command_line_attach_run): Use
gdb_is_target_native to check if test is supported.

Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0
gdb/testsuite/gdb.base/attach.exp