This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


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

Re: Extra Thread Info


>>>>> "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

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