remote validation

remote validation

[Denis PILAT]

I'd like to run a validation for a gdb hosted on linux and connected to 
a gdbserver also hosted on linux.
To simplify  the target is linux as well.

Is there a mean to configure the gdb testsuite so that it runs a 
gdbserver and connect the gdb to it ?

Thanks for your help, I can't find any document on that.

Re: remote validation

[Daniel Jacobowitz]

On Thu, Sep 21, 2006 at 04:26:55PM +0200, Denis PILAT wrote:
> I'd like to run a validation for a gdb hosted on linux and connected to 
> a gdbserver also hosted on linux.
> To simplify  the target is linux as well.
> 
> Is there a mean to configure the gdb testsuite so that it runs a 
> gdbserver and connect the gdb to it ?

Yes.  There's no board file in the standard DejaGNU, but all the
configury is there.  Here's mine; you could probably strip out some
of this.

=====snip======
# gdbserver running over ssh.

load_generic_config "gdbserver";

process_multilib_options "";

# The default compiler for this target.
#set_board_info compiler  "[find_gcc]";

# This is a gross hack.  We need to use the default compiler setting
# when testing GCC, or get_multilibs will break.
if { $tool == "gdb" } {
  set_board_info assembler  "arm-none-linux-gnueabi-as";
  set_board_info linker  "arm-none-linux-gnueabi-ld";
  set_board_info compiler  "arm-none-linux-gnueabi-gcc";
  set_board_info c++compiler  "arm-none-linux-gnueabi-g++";
}

set_board_info rsh_prog /usr/bin/ssh
set_board_info rcp_prog /usr/bin/scp
set_board_info protocol standard
set_board_info hostname myboardname
set_board_info username tools
#set_board_info gdb_server_prog /usr/bin/gdbserver
set_board_info gdb_server_prog /home/tools/gdbserver

# We will be using the standard GDB remote protocol
set_board_info gdb_protocol "remote"

# Name of the computer whose socket will be used, if required.
set_board_info sockethost "myboardname:"

# Use techniques appropriate to a stub
set_board_info use_gdb_stub 1;

# This gdbserver can only run a process once per session.
set_board_info gdb,do_reload_on_run 1;

# There's no support for argument-passing (yet).
set_board_info noargs 1

# Can't do input (or output) in the current gdbserver.
set_board_info gdb,noinferiorio 1

# Can't do hardware watchpoints, in general
set_board_info gdb,no_hardware_watchpoints 1;

global board_info 
set board_info(myboardname,rsh_prog) /usr/bin/ssh
set board_info(myboardname,rcp_prog) /usr/bin/scp
====snip====

-- 
Daniel Jacobowitz
CodeSourcery

gdbserver, was Re: remote validation

[Michael Snyder]

On Thu, 2006-09-21 at 10:33 -0400, Daniel Jacobowitz wrote:

> # There's no support for argument-passing (yet).
> set_board_info noargs 1
> 
> # Can't do input (or output) in the current gdbserver.
> set_board_info gdb,noinferiorio 1
> 
> # Can't do hardware watchpoints, in general
> set_board_info gdb,no_hardware_watchpoints 1;

Not to highjack the thread, but...  I'm wondering how much
interest / motivation there would be, to get a few of these
things (such as infiorior i/o) working in linux/gdbserver?

Re: gdbserver, was Re: remote validation

[Daniel Jacobowitz]

On Thu, Sep 21, 2006 at 01:51:11PM -0700, Michael Snyder wrote:
> On Thu, 2006-09-21 at 10:33 -0400, Daniel Jacobowitz wrote:
> 
> > # There's no support for argument-passing (yet).
> > set_board_info noargs 1
> > 
> > # Can't do input (or output) in the current gdbserver.
> > set_board_info gdb,noinferiorio 1
> > 
> > # Can't do hardware watchpoints, in general
> > set_board_info gdb,no_hardware_watchpoints 1;
> 
> Not to highjack the thread, but...  I'm wondering how much
> interest / motivation there would be, to get a few of these
> things (such as infiorior i/o) working in linux/gdbserver?

Args can be made to work with the current gdbserver; the harness starts
a new process each time and we can pass things on the gdbserver command
line.  Also, I have patches for another project which implement set
args directly over the remote protocol.  I just haven't gotten round to
submitting that one yet.

The infrastructure for hardware watchpoints is in place.  It just needs
more per-platform support, and some way to behave sensibly if the
target doesn't have any (the remote protocol behavior here is kind of
weak).

Inferior I/O is a heavy question.  I don't know.  I don't particularly
want to have gdbserver create slave ptys for this.

-- 
Daniel Jacobowitz
CodeSourcery