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

[Andreas Arnez <arnez@linux.ibm.com>]

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