Re: Eclipse and GDB Simulators

[Mike Frysinger <vapier at gentoo dot org>]

On Monday 11 February 2013 12:56:12 Joel Sherrill wrote:
> I was recently trying to get Eclipse to work with the Sparc Instruction
> Simulator in gdb. The setup worked great with an external simulator
> and real hardware but console output from sis was disappearing.
> 
> Chris Johns tracked it down to sis not wrapping its console output
> when attached to from Eclipse. I looked at a couple of other simulators
> but couldn't find where the "@" is prefixed to target stream output.
> 
> What is the proper way for a simulator to know it needs to prefix
> the "@"? How should this be done? Is there a good example?
> 
> sim/erc32/erc32.c seems a good case for a hard one to fix.
> It has two uarts which can be attached to files. The uart
> data is written using fwrite() a byte at a time and read with
> a call to read(). Knowing how to fix this one will give me
> a roadmap.
> 
> I am just worried about output now. But if target input is
> supposed to work in Eclipse, then I would like advice on
> how to proceed with that as well.
> 
> The RTEMS Community uses a lot of the gdb simulators and I
> was hoping to start sweeping through them to ensure target
> output works with Eclipse. But I would like to have a strategy
> for fixing issues.

does eclipse really need all of its output prefixed with an @ to work ?  that 
seems wonky.  i thought the console window just captured the normal 
stdin/stdout/stderr lines.  it's not like it'd be able to expect arbitrary 
programs to insert an @ when doing a normal compile/debug/run cycle.

the current "standard" is for uarts to do one of two things:
	- write via sim_io_write_stdout and read via sim_io_poll_read (which in 
turn use the callback mechanism and would be easy to override)
	- read/write via the dv-socker device which redirects via a socket

both are limited to basically only having 1 live UART at a time.  anything 
else is done ad-hoc on a per-sim implementation.

even if we assume eclipse can only handle one set of fds at a time and it has 
to be prefixed with an @, that doesn't help with the multi-UART scenario.

what would be optimal i think would be to fix the existing I/O subsystems to be 
loaded via the device tree.  this would require dv-sockser to not use global 
state (and thus not be limited to one connection), and it'd require a new dv-
fd-io device to be written that'd allow connecting of arbitrary fd's or files.  
if eclipse really truly wants that @ prefix, then maybe we can have that be an 
option to the dv-fd-io device (an arbitrary string to insert before every 
line).

note: it's been years since i last used eclipse, and when i did, i was doing 
ISA level simulation or JTAG debugging, so i wasn't expecting interaction via 
the console.  so i could be missing something obvious.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.