[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] remote protocol and signals
From: |
Theodore A. Roth |
Subject: |
Re: [Simulavr-devel] remote protocol and signals |
Date: |
Fri, 4 Jan 2002 16:02:58 -0700 (MST) |
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