Re: [Simulavr-devel] remote protocol and signals

[Theodore A. Roth]

On Fri, 4 Jan 2002, address@hidden wrote:

:)I like the change with the reentrant gdb_continue. It's better the function
:)itself knows what to do.

Yeah, I caught that when I made the changes.

:)
:)> I've still not decided whether to go with SIGHUP or 'Rxx' packets for 
:)> initiating a reset from gdb. I'm looking into the 'Rxx' mechanism now.
:)> 
:)> Anyone have any words of wisdom on this?
:)I don't know the extended remote protocol, but I think the extended remote
:)protocol is the better choice because:
:)
:)If you implement the signal solution, you can only do limited things (sending
:)a few signals).

Actually, try 'info signals' in gdb. There's a lot of signals you can 
send.

:)If you implement now only a subset of the extended remote protocol, we
:)are open to implement more of that protocol in the future. I hope that
:)protocol is an add on to the remote protocol.

You might want to look at the gdb info page for the remote protocol. It 
describes all the packets. I have notices that gdb-5.1 is trying to use 
some of the packets which are marked as reserved in the docs and it's not 
clear what the intent of the packets is.

In reality, there's not much to do in the sim for the extended protocol. 
It's mostly done in how gdb does some things differently internally, plus 
a few extra packets to handle on the remote side.

:)If that is true, we can implement now reset, or what ever you decide to be
:)necessary now.
:)If this is not true, it depends how much work it is to change from the remote
:)to the extended remote protocol.

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).

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.

Beware: this patch is named the same as the last one I sent.

Have a look and let me know what you think. The discussion is not closed 
yet.

Ted

sim-12-gdbserv-sig.patch
Description: Text document