[ECOS] gdb - info thread

[Phungte Ha]

Hi Gary,

I tried as you suggested and the result is the same.
Here for instance the output from 'info threads' after a Ctrl-C:

msr 9030!
Thread 2: and now a delay of 100 clock ticks
msr 9030!

Program received signal SIGINT, Interrupt.
hal_idle_thread_action (count=29665327)
    at /local/ecos-2.0/packages/hal/powerpc/arch/v2_0/src/hal_misc.c:274
(gdb) info thread
  2 Thread 2 ( Name: main, State: ready, Priority: 10 )  0xfffeadf0 in ?? ()
* 1 Thread 1 ( Name: Idle Thread, State: running, Priority: 31 )
hal_idle_thread_action (count=29665327)
    at /local/ecos-2.0/packages/hal/powerpc/arch/v2_0/src/hal_misc.c:274
(gdb)


Now if I pose a breakpoint in a thread routine and continue:

Breakpoint 2 at 0x19b10: file twothreads.c, line 94.
(gdb) c
Continuing.
Thread 0: and now a delay of 100 clock ticks
msr 9030!

Breakpoint 2, simple_program (data=10) at twothreads.c:94
(gdb) info thread
  2 Thread 2 ( Name: main, State: ready, Priority: 10 )  0xfffeadf0 in ?? ()
* 1 Thread 1 ( Name: Idle Thread, State: running, Priority: 31 )
simple_program (
    data=10) at twothreads.c:94
(gdb)


By trying to traceback on gdb-redboot (I'm lucky having
jtag for redboot), I can see the following:

My hal_vsr_table:
(gdb) x/20x &hal_vsr_table
0x3000:	0xfffe2300	0xfffe2300	0xfffe2300	0xfffe2300
0x3010:	0xfffe2300	0x00019634	0xfffe2300	0xfffe2300
0x3020:	0xfffe2300	0x00019634	0xfffe2300	0xfffe2300
0x3030:	0xfffe2300	0xfffe2300	0xfffe2300	0xfffe2300
0x3040:	0x00019634	0xfffe2300	0xfffe2300	0xfffe2300
(gdb)

routines at 0xfffexxxx are redboot's (rom), and those at 0x0001xxxx are
twothreads'.
The seventh vector is the one for program interrupt, which handles
trap/breakpoint,
it's redboot's.

This routine under redboot is cyg_hal_default_exception_vsr, which will uses
redboot's routines in generic-stub.c to answer to my info thread command.
Since the info is taken from there, it's redboot's, not from twothreads.

Using macro on the gdb-twothreads, I can parse the Cyg_Thread and get the
following:

(gdb) eIThreads
0x2dd88 Name: Thread c, Priority: 4, State: SLEEPING
0x28470 Name: Idle Thread, Priority: 31, State: RUNNING
0x2a5d8 Name: main, Priority: 10, State: EXITED
0x2dc38 Name: Thread A, Priority: 4, State: RUNNING
0x2dce0 Name: Thread B, Priority: 4, State: RUNNING
(gdb)

which can be almost a work-around...
The only problem is that I cannot switch to 'thread x' and 'backtrace' on
it!

I now wonder if I configured redboot and ecos correctly.


Redboot has Include GDB Stubs in HAL and Include GDB external break support
checked.
ecos has ROM Monitor support with 'Work with ROM monitor' checked.

Do you have an idea for me?

Thanks.

Phungte

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Thursday, June 10, 2004 12:36 PM
To: Phungte-Ha
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] gdb - info thread


On Thu, 2004-06-10 at 13:28, Phungte-Ha wrote:
> Hello all,
>
> I am running  twothreads.c on a ppc405 platform, which has redboot
> compiled with gdb multi-thread debug. The application is loaded using gdb,
> connected by serial line.
>
> Everything seems to work fine, but I wonder about info thread.
> I changed twothreads.c, added a 3rd thread to it, and info thread command
> invariably returns:
>
> (gdb) info thread
>   2 Thread 2 ( Name: main, State: ready, Priority: 10 )  0xfffeadf0 in ??
()
> * 1 Thread 1 ( Name: Idle Thread, State: running, Priority: 31 )
simple_program_2 (
>     data=4) at twothreads.c:122
> (gdb)
>
> The 3 threads started fine as stated by the printf from the application:
> [New Thread 1]
> 0xfffee85c in ?? ()
> $1 = 0x17400
> Entering twothreads' cyg_user_start() function
> resuming threads
> Beginning execution; thread data is 0
> Beginning execution; thread data is 1
> Beginning execution; thread data is 2
> Thread 0: and now a delay of 100 clock ticks
> Thread 1: and now a delay of 100 clock ticks
> Thread 2: and now a delay of 100 clock ticks
> Thread 0: and now a delay of 100 clock ticks
> Thread 1: and now a delay of 100 clock ticks
> Thread 2: and now a delay of 100 clock ticks
>
>
> The questions are:
>     . is the info thread command printing out the thread information of
>     redboot rather than the one from twothreads?
>     . is it possible to get real twothreads' thread information (the list
would
>     have at least 3 threads then) while running the application this way
>     (application running ontop of redboot, instead of gdb stub)?
>
> Thanks a lot for your ideas.

The 'info threads' command only tells you about the threads that exist
at the time of the command (since threads in eCos are totally dynamic).
I think that if you set a breakpoint somewhere in your program, *after*
the three threads have been created, it would tell you something quite
different than what you show.

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss