This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Extra Thread Info
- To: Stan Shebs <shebs at cygnus dot com>
- Subject: Re: Extra Thread Info
- From: jtc at redback dot com (J.T. Conklin)
- Date: 23 Nov 1999 13:31:54 -0800
- Cc: gdb at sourceware dot cygnus dot com
- References: <199911222334.PAA24695@andros.cygnus.com>
- Reply-To: jtc at redback dot com
>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I have a small GDB task for which I'm collecting opinions.
Stan> Should GDB include a special mechanism to get and display extra
Stan> info about threads? Right now GDB has a simple generic display
Stan> for threads: thread number, thread identifier, stack frame. The
Stan> thread identifier is a string that may vary from system to
Stan> system, but is generally expected to be a unique identifier of
Stan> some sort, such as "process 35 thread 217" or "thread 42.21".
I believe supporting extra thread info is a difficult problem because,
in general, there are an open ended number and set of types of thread
variables. These may be known for a given native config, but embedded
configs demand a more general approach.
Another problem is that we don't know what extra thread info is useful
to the user and what is extraneous. If we retrieve too much from the
target, "info threads" may take a very long time and the output may be
cluttered. If we retrieve too little, the user may not be able to get
at what he needs.
Besides your three suggestions, I prefer a fourth: provide target
specific user defined functions which traverse the thread table and
presents the information in a useful format. This doesn't bind any
knowledge about any particular thread implementation into GDB; is
easily modifyable by the end user (rather than a GDB hacker) to add,
remove, or change the presentation of thread information; and should
not require any changes to the target.
Stan> Opinions? I'd like to resolve this fairly quickly - eCos thread
Stan> info is one of the few areas where eCos GDB differs from regular
Stan> GDB, but there shouldn't be a difference at all. I'm presently
Stan> leaning towards the second choice, but don't feel strongly about
Stan> it.
If support for extra thread info is brought into GDB, I believe that
it must be "better" than what can be done by user defined functions.
Also, since that mechanism already exists and works well, I see no
reason to rush if the haste will result in something that we'll curse
in the years to come.
For reference, enclosed is a script I wrote to traverse the task list
on VxWorks.
--jtc
set $WIND_READY = 0x00
set $WIND_SUSPEND = 0x01
set $WIND_PEND = 0x02
set $WIND_DELAY = 0x04
set $WIND_DEAD = 0x08
define show_task
set $tcb = (WIND_TCB *) $arg0
printf "%-13.13s%8x %8x %3d ", $tcb->name, $tcb->entry, $tcb, $tcb->priority
if ($tcb->status == $WIND_READY)
printf "READY "
end
if ($tcb->status == $WIND_DELAY)
printf "DELAY "
end
if ($tcb->status == ($WIND_DELAY | $WIND_SUSPEND))
printf "DELAY+S "
end
if ($tcb->status == $WIND_PEND)
printf "PEND "
end
if ($tcb->status == ($WIND_PEND | $WIND_DELAY))
printf "PEND+T "
end
if ($tcb->status == ($WIND_PEND | $WIND_SUSPEND))
printf "PEND+S "
end
if ($tcb->status == ($WIND_PEND | $WIND_DELAY | $WIND_SUSPEND))
printf "PEND+S+T "
end
if ($tcb->status == $WIND_SUSPEND)
printf "SUSPEND "
end
if ($tcb->status == $WIND_DEAD)
printf "DEAD "
end
printf "\n"
end
define show_task_summary
set $n = activeQHead.pFirstNode
while $n != 0
set $tmp = ((WIND_TCB *) ((char *) $n - 0x20))
show_task $tmp
set $n = (Q_NODE *) $n->qPriv1
end
end
--
J.T. Conklin
RedBack Networks