Remote target (CRIS) DejaGNU config scripts

Remote target (CRIS) DejaGNU config scripts

[Orjan Friberg]

The CRIS target I'm running the DejaGNU testsuite on runs Linux.  Since 
I'm having problems running a few of the testcases and there seem to be 
quite a few DejaGNU configurations for remote targets I was wondering if 
the way I've implemented the CRIS-specific files is totally backwards. 
(There's no on-chip support for downloading code, like a monitor ROM or 
similar.)  Thanks in advance for any suggestions.

My gdb_load function uploads the file to the board via ftp, then logs in 
via telnet and starts gdbserver, after which it sets solib search paths 
and connects (over a socket).  Once connected, the program is stopped in 
_start in ld.so.1.

The baseboards file is what gives me headache, particularly 
gdb_init_command and start_symbol.  What I want to do is just to get to 
main in an orderly fashion.  What I currently have is:

set_board_info gdb_init_command "until main"
set_board_info gdb,start_symbol "(&main)"

The latter results in a "jump *(&main)" and is there because gdb_run_cmd 
in gdb.exp requires a start symbol (and tries to jump to "start" if I 
don't specify one).  Is there a cleaner way do accomplish this?  Or do I 
need to write a gdb_run_cmd of my own?

The problem I have with some testcases (like break.exp) is that they do 
runto_main in the middle of the testcase, which I can't do without 
repeating the procedure in my gdb_load.  This I assume is a problem 
common to many remote targets.  Setting do_reload_on_run doesn't play 
well with the above mentioned way of getting to main however.  In some 
cases I have simply inserted a "gdb_load $binfile" before runto_main, 
but I like to think there's a better way, since exiting gdb destroys any 
state it might have had.

-- 
Orjan Friberg
Axis Communications

Re: Remote target (CRIS) DejaGNU config scripts

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Thu, Feb 19, 2004 at 05:32:52PM +0100, Orjan Friberg wrote:
> The CRIS target I'm running the DejaGNU testsuite on runs Linux.  Since 
> I'm having problems running a few of the testcases and there seem to be 
> quite a few DejaGNU configurations for remote targets I was wondering if 
> the way I've implemented the CRIS-specific files is totally backwards. 
> (There's no on-chip support for downloading code, like a monitor ROM or 
> similar.)  Thanks in advance for any suggestions.

It sounds like you're doing this the hard way :)  If you are using
current CVS GDB, then you can use the gdbserver-sample.exp baseboard in
current DejaGNU as a template.  Please do change the paths - I have
absolutely no idea how that file I posted to gdb@ some months ago ended
up in a DejaGNU release :)

I've attached a modified version that I'm using as I type.  It works
pretty much OK.  You may need to change host_exec to server_exec in the
call to gdbserver_gdb_load in config/gdbserver.exp, depending on your
setup.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[-- Attachment #2: gdbserver-board.exp --]
[-- Type: text/plain, Size: 1342 bytes --]

# gdbserver running over rsh.

load_generic_config "gdbserver";

process_multilib_options "";

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

set_board_info assembler  "arm_v5t_le-as";
set_board_info compiler  "arm_v5t_le-gcc";
set_board_info c++compiler  "arm_v5t_le-g++";

set_board_info rsh_prog /usr/bin/rsh
set_board_info rcp_prog /usr/bin/rcp
set_board_info protocol standard
set_board_info hostname innovator
set_board_info username tools
set_board_info gdb_server_prog /usr/bin/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 "innovator:"

# Port ID to use for socket connection
# set_board_info gdb,socketport "4004"

# 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(innovator,rsh_prog) /usr/bin/rsh
set board_info(innovator,rcp_prog) /usr/bin/rcp

Re: Remote target (CRIS) DejaGNU config scripts

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> I've attached a modified version that I'm using as I type.  It works
> pretty much OK.  You may need to change host_exec to server_exec in the
> call to gdbserver_gdb_load in config/gdbserver.exp, depending on your
> setup.

Thanks Daniel, I think I'm halfway there.  One thing has me puzzled 
though, hostname vs. sockethost (from your example):

> set_board_info hostname innovator
> set_board_info sockethost "innovator:"

Substituting innovator with my board's IP address (10.13.8.125) this 
results in:

On the board: gdbserver 10.13.8.125:2346 <file>
On the host: target remote 10.13.8.125:2346

But the gdbserver should be started with the host's IP address as an 
argument, not the IP address of the board itself, right?  (Changing the 
sockethost variable to the host's IP address only results in the reverse 
situation, which means "target remote" will try and listen to a local 
port.)  Or am I totally missing something?

-- 
Orjan Friberg
Axis Communications

Re: Remote target (CRIS) DejaGNU config scripts

[Daniel Jacobowitz]

On Mon, Feb 23, 2004 at 04:37:08PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> >
> >I've attached a modified version that I'm using as I type.  It works
> >pretty much OK.  You may need to change host_exec to server_exec in the
> >call to gdbserver_gdb_load in config/gdbserver.exp, depending on your
> >setup.
> 
> Thanks Daniel, I think I'm halfway there.  One thing has me puzzled 
> though, hostname vs. sockethost (from your example):
> 
> >set_board_info hostname innovator
> >set_board_info sockethost "innovator:"
> 
> Substituting innovator with my board's IP address (10.13.8.125) this 
> results in:
> 
> On the board: gdbserver 10.13.8.125:2346 <file>
> On the host: target remote 10.13.8.125:2346
> 
> But the gdbserver should be started with the host's IP address as an 
> argument, not the IP address of the board itself, right?  (Changing the 
> sockethost variable to the host's IP address only results in the reverse 
> situation, which means "target remote" will try and listen to a local 
> port.)  Or am I totally missing something?

All you're missing is that gdbserver ignores the IP specified - it just
wants there to be a colon.  When I do it by hand I say ":5555". 
Theoretically, gdbserver should parse the IP, and make sure only to
accept a connection from that IP... but it doesn't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Remote target (CRIS) DejaGNU config scripts

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> All you're missing is that gdbserver ignores the IP specified - it just
> wants there to be a colon.  When I do it by hand I say ":5555". 
> Theoretically, gdbserver should parse the IP, and make sure only to
> accept a connection from that IP... but it doesn't.

Ah, yes, you're right.  Thanks.

-- 
Orjan Friberg
Axis Communications

Re: Remote target (CRIS) DejaGNU config scripts

[Orjan Friberg]

Ok, it seems to be working now (minus a hack in remote.exp because 
"username" had mysteriously disappeared).  One thing left though, 
setting the solib search paths.  Putting those commands in a .gdbinit 
file in the directory from where I run runtest didn't work, and I could 
neither find a suitable board_info variable to put it in, nor an option 
to runtest for it.  Any suggestions?

-- 
Orjan Friberg
Axis Communications

Re: Remote target (CRIS) DejaGNU config scripts

[Daniel Jacobowitz]

On Mon, Feb 23, 2004 at 05:33:10PM +0100, Orjan Friberg wrote:
> Ok, it seems to be working now (minus a hack in remote.exp because 
> "username" had mysteriously disappeared).  One thing left though, 
> setting the solib search paths.  Putting those commands in a .gdbinit 
> file in the directory from where I run runtest didn't work, and I could 
> neither find a suitable board_info variable to put it in, nor an option 
> to runtest for it.  Any suggestions?

Not really.  I used to use gdb_start_hook but that doesn't work for the
MI tests.  Nowadays I build GDB with --with-sysroot, which sets
solib-absolute-prefix automatically; that's all I need.  If you're
testing a Linux target it may be enough for you also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer