Remote target (CRIS) DejaGNU config scripts

[Orjan Friberg <orjan.friberg@axis.com>]

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