Re: Extra Thread Info

[Tom Tromey <tromey@cygnus.com>]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

Stan> However, an operating system may have additional info about
Stan> threads that the user would like to see.

Would this only happen at the OS level?

In a Java program, each (Java) thread has a name and a ThreadGroup.
It would be very useful to Java developers to see this information
when debugging Java programs.

Of course, that means interacting with the runtime.

Stan> but the current kod code needs more work to be useful for
Stan> threads in this way.  For instance, it asks for all types of
Stan> objects, but for threads we just want to ask about specific
Stan> threads.

Not only that, but KOD also has no way to map from the target's thread
id to gdb's thread id.  cf my KOD critique.  IMNSHO KOD is the wrong
way to go until it is redesigned and rewritten.

Tom
From jimb@cygnus.com Tue Nov 23 13:00:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: none
Date: Tue, 23 Nov 1999 13:00:00 -0000
Message-id: <npr9hg2a9t.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00315.html
Content-length: 2176

> > So, does the compiler use separate numbers in the debug for MMX
> > registers and FP stack registers, or the same numbers?
> > 
> > If the compiler uses separate register numbers, then we have the
> > problems discussed before: as far as I can tell, GDB simply isn't set
> > up to cope with the idea that certain bits might be part of two
> > registers.
> > 
> > If the compiler uses the same register numbers, how can the
> > architecture-specific code tell whether GDB is accessing MM0 (which
> > lives in R0) or ST(0) (which lives in R(TOS))?
> 
> The architecture-specific code knows about TOS, right?  It's part of
> the status word, so it's available to GDB.  Since TOS is handled the
> same by all x86 platforms, we could use the value of TOS to define two
> x86-specific functions to map between ST(i) and the corresponding MMj
> register and back.
> 
> Given these mapping functions, the code which implements the MMX view
> of the FP registers could allow both reading and writing MMX registers
> by accessing the corresponding ST(i) registers, each time using the
> current value of TOS.
> 
> Am I missing something obvious?  If so, perhaps I don't understand how
> the register views are (or would be) implemented.

For register views, yes, we can do anything we please.  However, when
the compiler places a register in an MMX register value, we still get
an old-fashioned symbol with a LOC_REGISTER.  Register views don't
come into it.  As long as we only have a LOC_REGISTER, we don't have
enough information to do the job right.

We could add a new symbol LOC type, LOC_REGISTER_VIEW, which produces
a struct value the same way a register view does.  Then, we could have
an architecture-specific hook can map certain register numbers in
debugging information onto LOC_REGISTER_VIEW, instead of LOC_REGISTER.
That might be the cleanest solution.

It remains to be seen whether I can persuade the maintainers to accept
register views at all.  They could reasonably argue that this is all
x86 hair, and should be isolated in x86 code.  And I also have the
feeling that there's something more general and cleaner we could do
here.  I'll need to think about it.
From jtc@redback.com Tue Nov 23 13:32:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 23 Nov 1999 13:32:00 -0000
Message-id: <5m7lj8x5bp.fsf@jtc.redbacknetworks.com>
References: <199911222334.PAA24695@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00316.html
Content-length: 3347

>>>>> "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
From shebs@cygnus.com Tue Nov 23 14:11:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 23 Nov 1999 14:11:00 -0000
Message-id: <199911232211.OAA25604@andros.cygnus.com>
References: <5m7lj8x5bp.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00317.html
Content-length: 2229

   From: jtc@redback.com (J.T. Conklin)
   Date: 23 Nov 1999 13:31:54 -0800

   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.

   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.

I didn't mention this option because it has a couple fatal flaws.
First, it doesn't work if the OS doesn't have a thread table.  What if
the OS calculates it on the fly, or expects the programmer to choose
the location of the table or whatever structure it is?

Second, it requires a set of symbols.  In your VxWorks example, you
manage to have WIND_TCB and activeQHead.pFirstNode available somehow.
I can't justify requiring an OS to expose its private data structures,
nor requiring users to link the definitions of the data structures
into their applications, whether or not the application uses those
structures directly.  (There is also a potential usability problem
with getting the compiler to include unused symbols in an executable.)

Third, there's no internal pathway for GUI clients to get the
information and do their own thing with it.  In other words, scripts
cannot presently be used to implement any part of a libgdb API.

An additional non-fatal objection is that GDB's scripting machinery is
too weak to depend on as an integral part of the debugger.  It's good
enough for people to develop scripts for use inhouse, but imagine
trying to manage and distribute dozens of configuration-specific
script files; it would be a disaster.  That's a good argument for a
more powerful scripting language, but nobody's working on one, so we
can't count on it being available soon enough to matter.

								Stan
From jimb@cygnus.com Tue Nov 23 14:15:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Bernard Mainguenaud <mainguen@gabin.frcl.bull.fr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Gdb target for kdb
Date: Tue, 23 Nov 1999 14:15:00 -0000
Message-id: <nppux02a48.fsf@zwingli.cygnus.com>
References: <199911231620.RAA29254@gabin.frcl.bull.fr>
X-SW-Source: 1999-q4/msg00318.html
Content-length: 657

> We intend to use gdb to debug a running Linux kernel connected
> to another Linux box via an asynchronous line. For this purpose,
> we are considering developping a new gdb target that interfaces
> with kdb. Has anyone ever tried to develop such a kdb target
> before ?

GDB has facilities for talking with ROM monitors.  You simply tell GDB
what the monitor's prompt looks like, how it prints registers, how it
dumps memory, and so on, and GDB will act as a very fast typist.  :)
Kdb's output might be close enough to a ROM monitor that this would
work.  

gdb/monitor.h describes the general principles, and any gdb/*-rom.c
file can furnish an example.
From taylor@cygnus.com Tue Nov 23 15:51:00 1999
From: David Taylor <taylor@cygnus.com>
To: Bernard Mainguenaud <mainguen@gabin.frcl.bull.fr>
Cc: gdb@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: Gdb target for kdb
Date: Tue, 23 Nov 1999 15:51:00 -0000
Message-id: <199911232344.SAA22324@texas.cygnus.com>
X-SW-Source: 1999-q4/msg00319.html
Content-length: 967

    From: Jim Blandy <jimb@cygnus.com>
    Date: 23 Nov 1999 16:04:07 -0500

    > We intend to use gdb to debug a running Linux kernel connected
    > to another Linux box via an asynchronous line. For this purpose,
    > we are considering developping a new gdb target that interfaces
    > with kdb. Has anyone ever tried to develop such a kdb target
    > before ?

    GDB has facilities for talking with ROM monitors.  You simply tell GDB
    what the monitor's prompt looks like, how it prints registers, how it
    dumps memory, and so on, and GDB will act as a very fast typist.  :)
    Kdb's output might be close enough to a ROM monitor that this would
    work.  

    gdb/monitor.h describes the general principles, and any gdb/*-rom.c
    file can furnish an example.

Another thing to look at is kgdb from Sun Microsystems.

Unfortunately, I don't know many of the details (esp. the precise
url).  If you do a search at www.sun.com it should find it.