Re: [ECOS] Debugging multi-threaded eCos application using GDB

[Jonathan Larmour <jlarmour at redhat dot com>]

Bart Veer wrote:
> 
> >>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> 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