simulavr-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]