Possible problem with SIS handling gdb/mi requests - quick fix?

[Fabrício de Novaes Kucinskis]

Hi all,

We use DDD to cross-debug our RTEMS applications. As DDD development seems
to be dead, we're trying to debug with Eclipse. This is fine for remote
debugging (real hardware), but there is a problem when using the GDB
built-in simulator for ERC32 (the Sparc Instruction Simulator, SIS). I
believe I've narrowed the source of the problem, as described below.

When calling GDB through Eclipse with SIS as target ('target sim'), I've
noticed that the simulator halts without informing the front-end – Eclipse
shows as if the program were running, and it isn't.

When I click 'suspend' on Eclipse, I see that SIS had run 3000 cycles. Then
I click 'continue' and another 'suspend', and see that more 3000 cycles were
run. Independent from the time lapse between a 'suspend' and 'continue'
commands, SIS is running and halting after 3000 cycles.

This doesn't happen when I use the command-line GDB or DDD. The difference
is that both use the GDB CLI interface, while Eclipse uses gdb/mi. I was
informed that there is a difference between CLI and gdb/mi events, and SIS
was designed long before gdb/mi existed.

I've studied the SIS source code and identified that there is an event in
erc32.c, 'uart_intr', that happens every 3000 cycles. This event calls
read_uart, flush_uart, and re-schedule for the next 3000 cycles. As
read_uart is executed by another event every 1000 cycles, I believe the
source of the problem I've detected is in the flush_uart function, that
contains the following code:

                while (wnuma && f1open)
                wnuma -= fwrite(wbufa, 1, wnuma, f1out);
    
                while (wnumb && f2open)
                wnumb -= fwrite(wbufb, 1, wnumb, f2out);

I think it’s possible that SIS halts at one of these loops, being freed only
after receiving a new gdb/mi command ('suspend') from the front-end.

But my current knowledge doesn't allow me to go any further. I hope someone
used to SIS and GDB code could quickly check this and perform a fix.

Thanks in advance and best regards,

Fabrício Kucinskis.