Extra Thread Info

Extra Thread Info

[Stan Shebs]

I have a small GDB task for which I'm collecting opinions.

Should GDB include a special mechanism to get and display extra info
about threads?  Right now GDB has a simple generic display for
threads: thread number, thread identifier, stack frame.  The thread
identifier is a string that may vary from system to system, but is
generally expected to be a unique identifier of some sort, such as
"process 35 thread 217" or "thread 42.21".

However, an operating system may have additional info about threads
that the user would like to see.  For instance, eCos threads (the
motivation for this task) have a name and other attributes, such as
priority and handle.  Similarly Posix threads have a scheduling
attribute, stack base, and stack size.  From the user's point of view,
these all ought to appear using the same commands; either in
"info threads", after the other data, or perhaps a new command
"info extra <thid>".  (I'm interested in opinions on that issue too.)

There appear to me to be three major approaches.

The first is to say "platform-specific", keep this out of GDB core
code, and implement display commands in platform-specific files.  This
is attractive for simplicity, but then every platform would likely
come up with different implementations and there would be less
consistency for users shifting between, say, eCos, Linux, and Solaris.

The second approach is to introduce a new optional target vector entry
that gets extra thread info.  Then "info threads" just gets any extra
info when requested, and dumps out whatever it gets back.  This is
what Cygnus' special GDB for eCos does now.

The third approach is to make use of the kernel object display (kod)
mechanism that was recently introduced.  This makes sense because
threads are just another kind of kernel object, but the current kod
code needs more work to be useful for threads in this way.  For
instance, it asks for all types of objects, but for threads we just
want to ask about specific threads.

Opinions?  I'd like to resolve this fairly quickly - eCos thread info
is one of the few areas where eCos GDB differs from regular GDB, but
there shouldn't be a difference at all.  I'm presently leaning towards
the second choice, but don't feel strongly about it.

								Stan

Re: Extra Thread Info

[Tom Tromey]

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

Re: Extra Thread Info

[Chris Faylor]

In article < 199911222334.PAA24695@andros.cygnus.com >,
Stan Shebs  <shebs@cygnus.com> wrote:
>I have a small GDB task for which I'm collecting opinions.
>
>Should GDB include a special mechanism to get and display extra info
>about threads?  Right now GDB has a simple generic display for
>threads: thread number, thread identifier, stack frame.  The thread
>identifier is a string that may vary from system to system, but is
>generally expected to be a unique identifier of some sort, such as
>"process 35 thread 217" or "thread 42.21".

This would be useful for Windows.  There is some information which would
be useful to know about a thread but there is currently no way to
display it.

When I added thread support for Windows I wished for an additional field
or two in gdb's thread structure which would have allowed me to store
extra OS specific state about a thread.  It would only have to be an
opaque void * pointer of use only to the target.  This would have saved
a fair amount of head-standing in win32-nat.c.

But, I don't think that this is exactly what you're talking about.
Having some kind of extensible way to query and report thread
information would be nice.  At the very simplest an additional target
vector could be supplied which returned extra information to tack onto
info thread output.

cgf
-- 
cgf@cygnus.com
http://www.cygnus.com/
From ebachalo@cygnus.com Wed Nov 24 18:18:00 1999
From: Eric Bachalo <ebachalo@cygnus.com>
To: rok.papez@kiss.uni-lj.si, gdb@sourceware.cygnus.com
Subject: Re: Gdb, threads, DDD and remote debugging.
Date: Wed, 24 Nov 1999 18:18:00 -0000
Message-id: <383C9C47.C69CE0D0@cygnus.com>
References: <99112302153403.01535@Strader.home>
X-SW-Source: 1999-q4/msg00324.html
Content-length: 1760

Rok Papez wrote:
> 
> Hello!
> 
> Could someon please RTFM me to some documentation that explains how to set-up
> gdb for remote debugging, either thru ethernet or serial cable. If used for

An online version of the GDB manual is located here:
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_toc.html


Remote debugging:
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html


Using GDB server.  I'm assuming you want to debug from a Linux host to a Linux
target.
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#SEC116

You will need gdbserver.  If you don't have a gdbserver you will need to build
one.  I would suggest doing an anonymously cvs check out of the latest
sources.  This will of course get you the latest gdb as well.  gdbserver has
been repaired recently for linux.  The gdbserver in last stable version of gdb
will not build under linux.

configure
make
make install

But unfortunately gdbserver is not made and installed automatically.  You will
need to go the to the gdb/gdbserver/ directory from where you configured and 
make; make install.

If you need help building from source let me know and I will give more
detailed info.


> remote debugging, are there any catches with multiple threads?

There is not much if any thread support, I believe.  This may change in the
future but no promises.


> Does DDD support remote debugging?

I am don't know whether DDD has support to use GDB remote debugging I have not
tried it.  If you like to use a GUI with GDB, may I suggest that you try
Insight.  It is very closely linked with GDB and does support remote
debugging.
http://sourceware.cygnus.com/insight/


> 
> Platform: x86, Linux, RH 6.0 with gdb-4.17.0.14-1
> 
> --
> best regards,
> Rok Papez.


Best Regards,

Eric Bachalo
From kevinb@cygnus.com Wed Nov 24 19:35:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: rok.papez@kiss.uni-lj.si, gdb@sourceware.cygnus.com
Subject: Re: Gdb, threads, DDD and remote debugging.
Date: Wed, 24 Nov 1999 19:35:00 -0000
Message-id: <991125033414.ZM13236@ocotillo.lan>
References: <99112302153403.01535@Strader.home> <rok.papez@kiss.uni-lj.si>
X-SW-Source: 1999-q4/msg00325.html
Content-length: 659

On Nov 23,  2:06am, Rok Papez wrote:

I see that Eric Bachalo answered your other questions.  I'll take 
a crack at this one...

> Does DDD support remote debugging?

DDD allows you to connect to a remote gdb (i.e, you can have gdb and
DDD running on separate machines).  You'll need to consult the DDD
documenation to find out how to make this work because it's been a
while since I've done it.  The only problem that I can recall with it
was that interrupting the gdb process from DDD did not work as well as
when both gdb and DDD were running on the same machine.

It may also be possible to use DDD and gdb with gdbserver, but I
have not tried it.

Kevin
From jlarmour@cygnus.co.uk Wed Nov 24 23:27:00 1999
From: jlarmour@cygnus.co.uk (Jonathan Larmour)
To: shebs@cygnus.com
Cc: msalter@cygnus.com, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Wed, 24 Nov 1999 23:27:00 -0000
Message-id: <199911250727.HAA31443@peshwari.cygnus.co.uk>
References: <199911240140.RAA25740@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00326.html
Content-length: 8339

In article < 199911240140.RAA25740@andros.cygnus.com > you write:
>
>   Date: Tue, 23 Nov 1999 19:34:19 -0500
>   From: Mark Salter <msalter@cygnus.com>
>
>   > 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?
>
>   I wouldn't think this is much of a problem. What if the OS calculates its
>   thread list on the fly? Presumably, a programmer has to write the code
>   that does this on the fly calculation. If you can do it in a programming
>   language, you should be able to do it in gdb's scripting language.
>
>Theoretically, yes.  But if you have to do a lot of accesses in order
>to accomplish a computation, packet traffic will be really bad.

This is definitely a big issue. With the current eCos-specific remote
protocol extensions, doing an `info threads' is a very laborious process
even at 38400 bps. At 9600 and, say, 30 threads, you may as well go home.
And of course that's what you have to do each time the target stops before
you do any thread operation to check that no threads have been
created/deleted while you weren't looking.

That is unless you make notification of these thread events part of the
protocol, which would potentially be a substantial improvement; but that
has problems because some of the extended thread info we are talking about
will be out of date unless you go back and refetch it all. Either that, or
have some ability to mark certain info to the user as potentially stale.
This is one of those times when a GUI could work better than a CLUI. 

The only alternative is (as JTC says) to be selective about the amount of
thread info requested.

>And
>you're still replicating the OS' algorithms in GDB scripts, which
>seems like a really bad idea; just because it's a script doesn't mean
>it won't be a maintenance problem. A minor user-invisible change to
>RTOS internals, and the script stops working.  I really don't want to
>be getting those kind of bug reports.

You could decide that any OS's that wanted to be supported by GDB should
provide a script fragment to include for their system. But in practice
that isn't generic. In eCos at least, the thread structure changes depending
on the kernel configuration. You could force systems like ours to make
autogeneration of a script fragment part of the configuration. Yuck. In
theory it would work, but in practice we'd probably prefer to have our
own set of GDB patches than do that. Maybe you think it's our own fault
we allow kernel configuration though :-).

>   > 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.)
>
>   You can't justify requiring an OS to export symbols, yet you could justify
>   requiring an OS to add an interface to support the remote protocol
>   thread packets.
>
>Perhaps the eCos developers' judgment is flawed, but they certainly
>preferred adding a packet over the alternative of encoding eCos
>internals into GDB, whether it was as scripts or C code.  But this
>decision was made a couple years ago; I'll bring it up with them
>again, perhaps they've changed their minds about this point.

Nope :-). At least not unless the scripts can adapt when the kernel thread
structure can change from program to program. Hard-coded C is right out.

It's feasible to enhance GDB scripting to do this right, but it certainly
isn't possible now. And then there are the other problems like it not
being usable from anything other than the CLUI. 

But it's the performance that's the real killer. Remote debugging over
wet string is slow enough, but add in the latency of script interpretation,
and having to synchronously query each item of thread state with separate
memory reads, and you have an unusable system. eCos is only requesting
the ID, name, and state in addition to the normal info, and the info is
returned in one packet per thread. But it takes around 1 second per thread
with a 38400bps link. It's not nice, but it we really must not do anything
to make it slower, which scripting would do a lot.

NB Other OS's may well find it very difficult to export internal structures
without actually having large sections of the OS itself compiled with
debug info, which may well be unacceptable. eCos doesn't mind as we're 
open source, but I don't think we should discriminate. The type information
encoded in the debug info is much more interesting than the actual symbols
of course.

>   The major advantage to exporting symbols is that it
>   does not change the memory footprint of an OS/application. This is often
>   critical when chasing bugs. At worst, an OS could export symbols from
>   key modules. Its not necessary to have symbols for everything. I've
>   written scripts to get thread info which relied only on a single
>   symbol being exported (a pointer to the head of the thread list).
>
>It's certainly always possible to write something that works for a
>particular situation.  My concern is that we're supposed to be
>supplying something that works consistently for users across both GDB
>and OS revs.

And ports of the same OS to different platforms where ABI and alignments
may vary. Surely all this is *exactly* the type of specific target
knowledge that remote stubs were designed for in the first place?
Otherwise, you may as well have just read/write memory commands in the
protocol and leave it at that!

If you are worried about memory footprint, then presumably this is an
embedded target in which case stubs can remain in ROM, which would
greatly reduce the memory footprint for a start. A stub ROM doesn't
need that much RAM. If the ROM gets obsoleted then it can just be
replaced, or the RAM-loaded program can be relinked with a new stub
implementation.

I think what is required is to draw up a list of all the thread concepts
we already know that users would want to know about: thread ID, name,
priority, state, stack frame at least. A target stub may support any or
all of these. 

When asked, the target can just return a bitmap all at once of the various
thread info "features" it supports. GDB would subsequently inquire about
the state of a particular thread by setting bits in a bitmap and sending
that in the request. The target would then return all the relevant thread
info at once. This would greatly reduce (or more accurately fine-tune) the
synchronous to-ing and fro-ing over the wire. We can extend this in future
by adding the ability to query individual features by string name, thus
allowing arbitrary data to be received and displayed. All these would be
cached of course.

It then becomes a user interface issue as to which bits of this information
GDB will be asked for. All the bitmap entries that GDB knows about can be
included in a "set threadinfo" command

So, for example 'set threadinfo id priority' would make GDB request the
id and priority only. A subsequent 'set threadinfo -priority +state' would
then make GDB request id and state each time.

And as I said above, you could ask for individual features by string
name, which could be: 'set threadinfo id priority state "CPU"', which would
send a bitmapped request for the first three fields, and then an individual
request for a "CPU" entry, which the remote stub can interpret and respond
to.

GUIs can do this in many easy and obvious ways which I'm sure I don't need
to describe. This was off the top of my head, so there may be flaws I
haven't thought of.

I think your average user would find hacking scripts that manipulate thread
structures directly a terrible way to achieve what can easily be done this
way. Not everyone is a GDB guru :-), nor do they even know or care about
the detailed implementation of the thread structures in their OS. They
just want to debug their own apps.

Jifl
From eliz@gnu.org Thu Nov 25 09:15:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: none
Date: Thu, 25 Nov 1999 09:15:00 -0000
Message-id: <199911251715.MAA09225@mescaline.gnu.org>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00327.html
Content-length: 672

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

I probably don't understand how this works.  How is the LOC_REGISTER
thing different from the case where the user specifies a certain
register (e.g., when the user wants to change its value)?  At any
given point in a debugging session, GDB knows what is the current TOS,
and therefore can map any MMX register to the corresponding ST(i),
right?
From per@bothner.com Sat Nov 27 12:11:00 1999
From: Per Bothner <per@bothner.com>
To: mark@codesourcery.com
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: debugging inline functions
Date: Sat, 27 Nov 1999 12:11:00 -0000
Message-id: <m2u2m766gs.fsf@magnus.bothner.com>
References: <199911271831.KAA21455@adsl-206-170-148-33.dsl.snfc21.pacbell.net>
X-SW-Source: 1999-q4/msg00328.html
Content-length: 3483

[I'm following up on a message Mark sent to gcc-patches, with the
subject "C++ PATCH to defer RTL generation for inlines", but since
this is more about design issues, and is gdb-related, I changed
the mailing lists.]

Mark Mitchell <mark@codesourcery.com> writes:

> Next will be to get debugging information correct for the inlined
> functions; at that point, I'll turn this stuff on by default.

I hope "getting debugging information correct" means doing better than
we traditionally have for inlined functions, which have been almost
impossible to use.  The problem is that if we're inside an inlined
function, Gdb is unable to show in its stack trace the *actual*
function, or rather the line number information is inconsistent
with the call stack information.  The bug is partly Gdb, partly the stabs
debug format, and partly the emitted debugging information.  Because
stabs does have a well-defined way to specify inlining, and Dwarf2 does,
it might be reasonable to concentrate on getting Dwarf2 debugging right.

I guess we should first define what "getting it right" means.  To me,
that means be able to show stack containing a mix on inlined and
regular calls in a way that makes sense.  Each stack frame must show
a consistent line number, function name, and parameter list.  Showing
a stack frame with the line number of the inlined function but with
the function name and arguments of its caller is just plain confusing,
as well as a pain to work with.

I see two choices:  Either we *drop* line numbers from inlined code
(i.e. pretend the entire inlined function is like a macro that
appears in the call site line), or we do it *right*.  The current
half-assed approach is worse than nothing; it makes it very difficult
to debug optimized C++ code.

The right approach is to add "pseudo-stack-frames" for the inlined
functions.  I vaguely remember the Mips debugger had pseudo-frames for
lexical blocks, not just for entire functions.  That may be overkill
(though it allows you to see "shadowed" variables), but once you have
that, it is trivial to add pseudo-frames for inlined functions.

The stack frame for an inlined function should should ideally show the
line (and column) number in the lined function, the name of the
inlined function, and the parameter list.  Gettting the parameter
values is easy: We must generate stabs for:

        inline int foo(int i)   // line 100
        {                       // line 101
          int k = 2 * i;        // line 102
          return k + i;         // line 103
        }                       // line 104
        ...
        foo (10)                // line 200
as if the code was:
        {
          int i = 10;           // line 200
          {
            int k = 2 * i;      // line 102
            return k + i;       // line 103
          }
        }

What we need to do is also annotate the block that defines the inlined `i'
that this is an inlined procedure, and that `i' is one of the parameters.
With that information, we can generate a correct stack trace.

So the task for Gcc is to generate debug information that allows
this information to be extract.  For dwarf2, I assume there is a spec
we can follow.  For stabs, we can add a descriptive string (such as "foo(i)")
to the "begin block" symbol.

Maybe once Gcc generates the correct debug information, it may be
possible to motivate the Gdb people to do the right thing with it ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/
From alexs@cygnus.co.uk Sat Nov 27 18:49:00 1999
From: "Alex Schuilenburg" <alexs@cygnus.co.uk>
To: gdb@sourceware.cygnus.com
Subject: Multi-threaded debugging within GDB & eCOS
Date: Sat, 27 Nov 1999 18:49:00 -0000
Message-id: <77kid9$pqp$1@korai.cygnus.co.uk>
X-SW-Source: 1999-q4/msg00329.html
Content-length: 927

Could someone describe how gdb would handle the following situation in
debugging multiple threads using gdb (particularly on eCOS)? Has anyone
thought of this scenario before?

1) gdb is tracking thread A, which claims a system mutex.
2) Either a context switch occurs or the user suspends thread A and
   switches to debugging thread B (which itself is suspended).
3) While stepping over fn calls within B, the code attempts to claim
   the mutex already owned by A. Hence B will never return from the call
   to the next temporary breakpoint until A is resumed and releases the
   mutex.

Will gdb lock up? Is there any mechanisim to allow gdb to detect/catch this
scenario and report back to the user what has happened?

I have some idea on how this could be handled (having written a gdb/debug
type debugger for a multi-threaded RTOS) but would like to know the
specifics within eCOS/gdb.

-- Alex

Re: Extra Thread Info

[Stan Shebs]

   Date: Tue, 23 Nov 1999 19:34:19 -0500
   From: Mark Salter <msalter@cygnus.com>

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

   I wouldn't think this is much of a problem. What if the OS calculates its
   thread list on the fly? Presumably, a programmer has to write the code
   that does this on the fly calculation. If you can do it in a programming
   language, you should be able to do it in gdb's scripting language.

Theoretically, yes.  But if you have to do a lot of accesses in order
to accomplish a computation, packet traffic will be really bad.  And
you're still replicating the OS' algorithms in GDB scripts, which
seems like a really bad idea; just because it's a script doesn't mean
it won't be a maintenance problem.  A minor user-invisible change to
RTOS internals, and the script stops working.  I really don't want to
be getting those kind of bug reports.

   > 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.)

   You can't justify requiring an OS to export symbols, yet you could justify
   requiring an OS to add an interface to support the remote protocol
   thread packets.

Perhaps the eCos developers' judgment is flawed, but they certainly
preferred adding a packet over the alternative of encoding eCos
internals into GDB, whether it was as scripts or C code.  But this
decision was made a couple years ago; I'll bring it up with them
again, perhaps they've changed their minds about this point.

   The major advantage to exporting symbols is that it
   does not change the memory footprint of an OS/application. This is often
   critical when chasing bugs. At worst, an OS could export symbols from
   key modules. Its not necessary to have symbols for everything. I've
   written scripts to get thread info which relied only on a single
   symbol being exported (a pointer to the head of the thread list).

It's certainly always possible to write something that works for a
particular situation.  My concern is that we're supposed to be
supplying something that works consistently for users across both GDB
and OS revs.

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

   A gui can do what a gdb script does and use memory read operations
   to get the info it needs.

Which means that each GUI now has to have its own version of the same
thread-groveling script?  Sounds like an MxN problem.  GDB is supposed
to be a toolbox for debugging; it's silly to get rid of all the useful
tools, and say "here are some blocks of iron and wood, you can use
these to build everything else you might need".

(Lest anybody be misled, I believe that one of the requirements for
the scripting language *should* be that it can implement parts of a
libgdb API.  That is, one can write scripts that create and manipulate
the objects that the API would make available to the library's
clients, such as breakpoints and threads.)

   > An additional non-fatal objection is that GDB's scripting machinery is
   > too weak to depend on as an integral part of the debugger.

   Let's get rid of the weaknesses :-)

The current round of GDB internal changes took four years from
proposal to implementation.  I'm not that optimistic about improved
scripting being available soon.  In the meantime, people are using
proprietary debuggers instead of GDB, in part because those debuggers
include the specific RTOS support that we're being reluctant to add.
To quote RMS, commenting in the GCC manual on GCC's architecture:
"Elegance, theoretical power and simplicity are only secondary."

   The major flaw that I see with requiring OS support to get thread info
   is that it requires target code to run. If you are running in a 
   simulation environment, then you end up in the awkward position of
   having to run the simulator to get information about the system being
   simulated. Another disadvantage is that you can't extract thread
   information from a dumped core file for those systems able to
   generate one.

You make some very good points here; but I'm not talking about
*requiring* OS support to get extra thread info.  I'm proposing an
optional capability that is available for any system that wants to use
it.  Also note that GDB's remote protocol already requires the target
OS to supply basic thread info via specialized packets; the protocol
has worked this way for some years, and so far everybody seems to be
OK with that.  All I'm talking about is adding another degree of
extensibility to the existing system.

								Stan

Re: Extra Thread Info

[Mark Salter]

>>>>> Stan Shebs writes:

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

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

I wouldn't think this is much of a problem. What if the OS calculates its
thread list on the fly? Presumably, a programmer has to write the code
that does this on the fly calculation. If you can do it in a programming
language, you should be able to do it in gdb's scripting language.

> 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.)

You can't justify requiring an OS to export symbols, yet you could justify
requiring an OS to add an interface to support the remote protocol
thread packets. The major advantage to exporting symbols is that it
does not change the memory footprint of an OS/application. This is often
critical when chasing bugs. At worst, an OS could export symbols from
key modules. Its not necessary to have symbols for everything. I've
written scripts to get thread info which relied only on a single
symbol being exported (a pointer to the head of the thread list).

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

A gui can do what a gdb script does and use memory read operations
to get the info it needs.

> An additional non-fatal objection is that GDB's scripting machinery is
> too weak to depend on as an integral part of the debugger.

Let's get rid of the weaknesses :-)

The major flaw that I see with requiring OS support to get thread info
is that it requires target code to run. If you are running in a 
simulation environment, then you end up in the awkward position of
having to run the simulator to get information about the system being
simulated. Another disadvantage is that you can't extract thread
information from a dumped core file for those systems able to
generate one.


--Mark