This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |