diff mbox

[3/3] Fix a FAIL in attach.exp under native-extended-gdbserver

Message ID 1521043903-18837-4-git-send-email-arnez@linux.vnet.ibm.com
State New
Headers show

Commit Message

Andreas Arnez March 14, 2018, 4:11 p.m. UTC
The attach.exp test case yields a FAIL with native-extended-gdbserver when
trying to start a new process.  This is because gdbserver does not support
starting new processes.  And since the gdbserver-base board file sets the
GDB command line option -ex "set auto-connect-native-target off", the
process is not started on the native target either.  An error message
results instead:

  Don't know how to run.  Try "help target".

Thus just accept this error when not running on a native target.

gdb/testsuite/ChangeLog:

	* gdb.base/attach.exp: Accept the error message "don't know how to
	run" when not running on a native target.
---
 gdb/testsuite/gdb.base/attach.exp | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Simon Marchi March 15, 2018, 10:16 p.m. UTC | #1
Hi Andreas,

On 2018-03-14 12:11 PM, Andreas Arnez wrote:
> The attach.exp test case yields a FAIL with native-extended-gdbserver when
> trying to start a new process.  This is because gdbserver does not support
> starting new processes.  And since the gdbserver-base board file sets the
> GDB command line option -ex "set auto-connect-native-target off", the
> process is not started on the native target either.  An error message
> results instead:
> 
>   Don't know how to run.  Try "help target".
> 
> Thus just accept this error when not running on a native target.

It is not true that gdbserver can't run a new process, in fact it can in the
extended-remote protocol (as opposed to remote).  Start gdbserver with:

 $ ./gdbserver/gdbserver --once --multi :1234

And

 $ ./gdb --data-directory=data-directory
 (gdb) tar ext :1234
 (gdb) set remote exec-file /usr/bin/gnome-calculator
 (gdb) run

Still, I first thought this test wouldn't be applicable to the extended-remote
protocol because I though you couldn't mix -p with connecting to a remote target
on startup, but it seems like this works:

 $ pidof gnome-calculator
 20001
 $ ./gdb --data-directory=data-directory -iex "tar ext :1234" -p 20001  -ex "set remote exec-file /usr/bin/gnome-calculator" -ex "start"

So it might be possible to tweak the test case to adapt it to the extended-remote
protocol (add the -iex and "set remote exec-file" bits).

Simon
Andreas Arnez April 25, 2018, 9:30 a.m. UTC | #2
Sorry for the delay...

On Thu, Mar 15 2018, Simon Marchi wrote:

> Hi Andreas,
>
> On 2018-03-14 12:11 PM, Andreas Arnez wrote:
>> The attach.exp test case yields a FAIL with native-extended-gdbserver when
>> trying to start a new process.  This is because gdbserver does not support
>> starting new processes.  And since the gdbserver-base board file sets the
>> GDB command line option -ex "set auto-connect-native-target off", the
>> process is not started on the native target either.  An error message
>> results instead:
>> 
>>   Don't know how to run.  Try "help target".
>> 
>> Thus just accept this error when not running on a native target.
>
> It is not true that gdbserver can't run a new process, in fact it can in the
> extended-remote protocol (as opposed to remote).  Start gdbserver with:
>
>  $ ./gdbserver/gdbserver --once --multi :1234
>
> And
>
>  $ ./gdb --data-directory=data-directory
>  (gdb) tar ext :1234
>  (gdb) set remote exec-file /usr/bin/gnome-calculator
>  (gdb) run

Thanks, you're right, of course.

What really happens here is that attach.exp tries to start GDB with the
command line options "--pid=<pid>" and "-ex start", using
gdb_spawn_with_cmdline_opts.  However, gdb_spawn_with_cmdline_opts is
not overridden in native-extended-gdbserver.exp.  Thus we just fire up
GDB without setting an extended-remote target, and without having
started gdbserver.  And due to "auto-connect-native-target off", the
"start" command then responds with the error message above.

The test suite contains some other "gdb_spawn*" invocations, all having
the same problem.  To fix this, we should override these procs.

>
> Still, I first thought this test wouldn't be applicable to the extended-remote
> protocol because I though you couldn't mix -p with connecting to a remote target
> on startup, but it seems like this works:
>
>  $ pidof gnome-calculator
>  20001
>  $ ./gdb --data-directory=data-directory -iex "tar ext :1234" -p 20001  -ex "set remote exec-file /usr/bin/gnome-calculator" -ex "start"
>
> So it might be possible to tweak the test case to adapt it to the extended-remote
> protocol (add the -iex and "set remote exec-file" bits).

Actually, after investigating this a bit further I wonder why "set
remote exec-file" should even be necessary.  In the native case GDB
takes care of this for the user, if possible.  And this is exactly what
the test case tries to verify here.  IMHO extended-remote should behave
the same.  So I think the current behavior is a usability bug and should
be fixed.

I've been working on some patches for this.  I'll send them around
later.

--
Andreas
diff mbox

Patch

diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp
index efec49e385..1651dc40a7 100644
--- a/gdb/testsuite/gdb.base/attach.exp
+++ b/gdb/testsuite/gdb.base/attach.exp
@@ -421,11 +421,18 @@  proc test_command_line_attach_run {} {
 
 	send_gdb "y\n"
 
+	set cantrun 0
 	set test "run to main"
 	gdb_test_multiple "" $test {
 	    -re "Temporary breakpoint .* main .*$gdb_prompt $" {
 		pass $test
 	    }
+	    -re "Don't know how to run..*$gdb_prompt $" {
+		set cantrun 1
+	    }
+	}
+	if { $cantrun && [gdb_is_target_native] } {
+	    fail $test
 	}
 
 	# Get rid of the process