From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: bartv@redhat.com Cc: Stefan.Syberichs@ascom.ch, ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Debugging multi-threaded eCos application using GDB Date: Fri, 03 Aug 2001 08:11:00 -0000 Message-id: <3B6ABF02.4A91A194@redhat.com> References: <200108031439.f73EdOE25094@sheesh.cambridge.redhat.com> X-SW-Source: 2001-08/msg00123.html Bart Veer wrote: > > >>>>> "Jifl" == Jonathan Larmour writes: > > Jifl> Actually I would have thought the easiest route would be to > Jifl> allow included stubs in the synth target to be available at > Jifl> a socket, and then using the remote protocol. Making it > Jifl> available as a socket should "just" be a case of adding a > Jifl> virtual vectored comm interface. It's probably a bit too > Jifl> much work for us to just do for fun, particularly since the > Jifl> synth target doesn't use virtual vectors at all right now. > > I don't how this could sensibly work for the synthetic target. We are > not using the remote protocol, we are using native debugging. > > Yes, theoretically it would be possible to run something like Redboot > inside the synthetic target, connect to it via a socket and the remote > protocol, and then boot a RAM-startup synthetic target application > into it. That's what I was thinking sort of - except you could just build your application for "ROM" startup and include stubs instead. After all, this only applies if you explicitly want thread debugging. > When debugging the target would run in polled mode, which is > now what you want for a synthetic application. Interrupting a running > program would involve detecting SIGIO on the socket from gdb and doing > the right thing, not impossible but messy. A call to sigaction - I don't think that's a big deal. And polling isn't a prerequisite - when waiting for input from GDB you can just do a blocking read. > I would much prefer to > avoid this route. Fixing the problem in gdb instead would give a clean > and general-purpose solution. I'm not sure about clean for *GDB*, and I think it would be very difficult to do right: The biggest problem is that even the layout of the kernel structures depend on the configuration - just look at the definition of Cyg_Thread - and that's not the only structure to analyse. Perhaps a hybrid approach to yours may be to make sure that inferior calls worked with the synthetic target, and write a series of GDB macros that did the equivalent of info threads, but by calling into eCos. But there can definitely be problems with this approach wrt interrupts and effectively asynchronous state. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine