This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Remote target (CRIS) DejaGNU config scripts
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 19 Feb 2004 17:32:52 +0100
- Subject: Remote target (CRIS) DejaGNU config scripts
- Organization: Axis Communications
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