This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]