[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] New 0.0.13-pre1 works well
From: |
Theodore A. Roth |
Subject: |
Re: [Simulavr-devel] New 0.0.13-pre1 works well |
Date: |
Thu, 3 Jan 2002 23:02:48 -0700 (MST) |
On Fri, 4 Jan 2002, address@hidden wrote:
:)I have discoverd, that it is possible to restart a simulation without
:)rerun of simulavr. I used the load command to do this. This will set
:)the registers including the PC. gdb will set the PC to 0 with this
:)command.
Gdb doesn't send anything that anything to the remote that will let it
know that you want to reset the simulavr's state. Something needs to
happen such that gdb can send a reset signal. Using 'load' is not enough.
For instance, I can see that once I run up to a breakpoint and then issue
a 'load' command from gdb, the sim's sreg value is unchanged. Not really
what you want. I've got some ideas, see below.
:)
:)I don't know what you are plan to do with the extended protocol, but I
:)think if we add a detection in gdb_write_registers, that the PC is set
:)to 0, we can interpret this as a target reset and restart the
:)simulation. This detection is maybe not necessary until now (don't
:)know the details inside the simulator), but if the external interface
:)is connected, we need to send a reset command to this external
:)interface.
:)
:)What do you think?
I just ran gdb using 'target extended-remote ....' Here's what I found:
Issuing a 'kill' command in gdb causes gdb to send a 'k' packet to sim.
Gdb keeps the session open assuming that it can still talk to the sim, but
the sim got the 'k', so it stopped.
Looking through the gdb docs, I see that the extended remote protocol will
let us have gdb send an 'R' packet (remote restart) to the sim. The sim
could catch this and call avr_core_reset(). This would be trivial to
implement on the sim side. I'm not sure yet how to generate that 'R'
packet. If I can't find an existing command, it's not that hard to add a
new command in the avr gdb patch.
Another option, would be to issue a 'signal <signo>' command in gdb to
have it pass a signal to the simulator. SIGHUP would be the obvious
choice. This might be the best solution. It'd only take a few lines of
code on the sim side, and is already on the gdb side. Plus, it would work
without having to use extended-remote. You'd just do this:
(gdb) signal SIGHUP
(gdb) load
The way the sim works now, the closest you can come to this is to start
the sim in server mode, start avr-gdb, debug, and quit gdb. When gdb
closes the session, it sends a 'k' packet which causes the sim to exit the
processing loop, reset itself and then wait for a new connection from gdb.
You can start up avr-gdb again without having to start another instance of
the sim. This works well for me, but I'm not doing any serious debugging
of avr programs with the simulator.
I've got to do bit more research on this.
Ted