Re: [Simulavr-devel] remote protocol and signals

[Theodore A. Roth]

[ Scott, do you have anything to add to this discussion? How do you deal
with resets with avarice? I think the results of the decision may end up
affecting avarice. ]

more below. (I've included most of original message for benefit of those 
who didn't receive it)

On Sat, 5 Jan 2002, address@hidden wrote:

:)> Actually, try 'info signals' in gdb. There's a lot of signals you can 
:)> send.
:)Really a lot. So we can use other signals in the future also.
:)
:)<snip>
:)
:)> I haven't been able to gain access to the 'Rxx' packet from any of the 
:)> existing gdb commands. I don't see an easy way to do it that will not 
:)> bloat the gdb patch and just be a mess. (I may have already over stepped 
:)> the bloat boundary by adding the 'info io_registers' command).
:)But this is in avr-tdep.c and I think this is acceptable.
:)I think addind a command, which sends the 'Rxx' packet, to remote.c is 
allowed,
:)because it seems that it is missed. I think it will be accepted by the gdb
:)developers.
:)
:)The only place where it is sent, is in function extended_remote_restart in
:)remote.c.

You are correct about extended_remote_restart().

The hard part is in how you have to set things up to allow this to be
called. It's not a simple matter of adding an avr_reset command to gdb
(adding commands _is_ trivial) and having the command call
extended_remote_restart(). Since extended_remote_restart() is a static
private function, we can't call it directly from avr-tdep.c. If it was 
that easy, I'd already have done it and we'd be done.

As far as I can tell, we would have to write and install a new target to
all this which would not be as clean a solution as I'd like to see. See
avr-rom.c from the old gdb-5.0-avr-patch-0.1 patch for an example of what
I'm thinking we _might_ have to do. What research I've done on this seems
to point in that direction, although I still need to do some more
research.

:)
:)> Unless someone can tell me about an existing gdb command which will send
:)> the sim an 'Rxx' packet, I think we're stuck with the signal method.
:)> 
:)> The signal method is really much easier to implement. I've already done it
:)> and it works well (haven't checked it in yet). You don't even have to give
:)> the 'load' command to get things going again. I think we're ok to do this 
:)> as long as it's documented well (I've done that too). Signals from gdb in 
:)> this manner, really don't make much sense to the avr programs running in 
:)> the sim. Thus, we can use most of them as 'out of band' data for the user 
:)> to pass information from gdb to the simulator.
:)> 
:)> I'm aiming for a simple to use, simple to implement approach. I'm only 
:)> worried that the SIGHUP method is not intuitive enough.
:)> 
:)> Attached is a patch implementing the signal method. It works well. Only 
:)> problem I have is that avr_core_reset() isn't resetting the working 
:)> registers, but that will be easy to fix and is a problem regardless of the 
:)> method used to call it.
:)> 
:)> Have a look and let me know what you think. The discussion is not closed 
:)> yet.
:)I agree wih you. After looking to the documentation. And I also thing SIGHUP
:)is not intuitive enough. So we must document it (where?) or implement the 
reset
:)command.

SIGHUP makes some sense if you are familiar with daemon processes on Unix.  
In reality though, I doubt that many of simulavr's users will have that
familiarity. I've already implemented the SIGHUP method and it works
without any more changes to gdb.

Here's my proposal. We leave the SIGHUP in and document it. We defer until
0.1.x the gdb 'reset' command method which will send the 'Rxx' packet to
remote targets and investigate a cleaner may to implement it in the mean
time. I do think there should be an intuitive command to perform a reset. 

Does anyone have any objections to implementing both methods?

:)
:)As I read the docu and gdbserver.c I saw that there are much more things to
:)implement than the reset:
:)writing sram
:)write, read and access watchpoints
:)continue on an other address

Noted. See road map message.

:)
:)The PIC simulator can add breakpoints on register access, read, write in
:)general or with a value. I know this can be done also with a memory
:)watchpoints, but does anybody know where the registers are located? We could
:)define a shortcut for this.
:)
:)If we implement the watchpoints, we must take care that this will not increase
:)the needed execution time. The PIC simulator has a nice implementation to
:)do this with only a little impact. It is is based on C++ inheritance. We need
:)to discus this if start to think about it.
:)


Ted