Re: [Simulavr-devel] gdb interrupts

[reinhard . jessich]

On Wed, 02 Jan 2002, Theodore A. Roth wrote:
> Alright, I've figured this out.
> 
> When the user hits C-c from the gdb command line, gdb will send a byte 
> (0x03) down the line. It is _not_ wrapped by the "$...#cc", thus you don't 
As I analysed the problem I saw this. I thought you know this, because I have
seen a comment in gdb_main_loop which says ".... in a stepping loop and I hit
C-c in gdb".
Sorry, I could have pointed you to this.

> see a packet sent (no packet is sent!). But gdb did tell us that it sent 
> the interrupt. So... gdb is doing the right thing. We need to modify 
> gdbserver.c as Reinhard suggested to be able to handle processing 
> unexpected events.
> 
> Right now, simulavr will catch the 0x03 byte (if it's not in executing
> insn's) and reply with a "S04" packet. Of course, this is wrong.
I don't know what gdb expects, but I thing it expects that what you are doing
if you enter <cntr-c> in simulavr. So the only thing that must be done is
breaking the loop in gdb_continue. But this must be done without the ugly
goto's. You should use goto's very rarely and only if it is not possible to do
it in a structured way. gdb_continue is the example why goto's are so
dangerous. The code befor the patch hasn't installed the default interrupt
handler, because the goto jumps across the uninstall.
Anyway, now the code is ok.

> Here's what I'm going to try. After simulavr executes an instruction, have 
> it do a nonblocking read on the socket fd. If data is ready, it will have 
> to process it and handle it appropriately then maybe go back to executing 
> instructions.
> 
> I'm thinking about adding another element to the core struct which would
> be a hook that gdbserver.c will install a function into to perform the
> operation. This way another interface could hook into the core if
> gdbserver.c is not being used and the core needs to know nothing about it
> except to call the function if the pointer is not NULL. If the hook
> function returns non-zero, then simulavr should break out of the execution
> loop.
> 
> Comments?
I don't think that this is necessary now. I haven't seen the need for such a
hook in a avr_core_step. I think we shall implement features, if we need them.

If you plan to move the execution loop into the core, then your approach is
correct. For the long term we will move the loop to the core, because there
will be more things handled in the loop in the future and I don't like to
implement them twice in the gdbserver and in the run function in avr core.

Reinhard

-- 
 Ing. Reinhard Jessich              mailto: address@hidden
 A-1190 Vienna, Goergengasse 2/2/1  phone: +43/1/3692600
 http://members.telering.at/jessich mobile: +43/664/1735439