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


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

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