[Bug sim/12722] New: Lack of support for gdb/mi on Sparc Instruction Simulator

["fabricio at dea dot inpe.br" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12722

           Summary: Lack of support for gdb/mi on Sparc Instruction
                    Simulator
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: critical
          Priority: P2
         Component: sim
        AssignedTo: unassigned@sourceware.org
        ReportedBy: fabricio@dea.inpe.br


[source: http://sourceware.org/ml/gdb/2011-04/msg00148.html]

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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.