This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug sim/12722] New: Lack of support for gdb/mi on Sparc InstructionSimulator
- From: "fabricio at dea dot inpe.br" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 2 May 2011 12:48:07 +0000
- Subject: [Bug sim/12722] New: Lack of support for gdb/mi on Sparc InstructionSimulator
- Auto-submitted: auto-generated
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.