This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Thread debugging sans stubs


On Wed, Oct 03, 2001 at 02:57:07AM +0100, Jonathan Larmour wrote:
> Grant Edwards wrote:
>
> > I've got a thread that stops running occasionally, and I'm
> > trying to figure out why.  Since I'm using a JTAG interface, I
> > don't have the thread support provided by GDB stubs.  I can
> > print out the thread object, but don't know how to interpret
> > it. Is there any documentation that explains how to figure out
> > things like the thread's current IP,
> 
> Not really. But if saved_context == 0, this must be the current thread

According to GDB, execution was stopped in idle_thread_action,
so isn't the idle thread the current one?

(gdb) bt
#0  0x1fe58 in hal_idle_thread_action (count=621893252) at [...]/arch/current/src/hal_misc.c:197
#1  0x21930 in Cyg_HardwareThread::thread_entry (thread=0x86640) at [...]/kernel/current/src/common/thread.cxx:96

> so the registers are on the stack, i.e. up from stack_ptr.
> You'll have to unwind the stack by hand, using
> HAL_THREAD_GET_SAVED_REGISTERS for your arch to indicate what's
> required - which for ARM is just a HAL_SavedRegisters struct.
> 
> > and if/why the thread is blocked?
> 
> For "if" look at state and compare with what's in thread.hxx.

OK, state=1, which is SLEEPING

> For "why" look at "queue" and find out what object that queue
> is associated with.

That's the bit of info I was looking for.  I had been looking
at wait_info and wasn't getting anywhere (it doesn't seem to be
used by mutex code).

Now I know what mutex it's waiting for and who owns it!

-- 
Grant Edwards
grante@visi.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]