Extra Thread Info

[Mark Salter]

>>>>> Stan Shebs writes:

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

I wouldn't say their judgement is flawed. I would agree with their
decision if debugging using the remote protocol were the only 
debugging environment to be considered. But you erect a strawman, here.
I never suggested encoding eCos (or any other) OS internals in gdb.

  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.

I wasn't aware that the eCos group was the sole arbiter of this issue.

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

GDB shouldn't have to worry about OS revs. I'm assuming that the script
to extract thread info from a target is provided and maintained by the
OS vendor, not the gdb maintainers.

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

No, the OS vendor-supplied thread-groveling scripts provide an interface
to thread info that can be used from a CLUI or from a GUI.

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

This solution by definition, only works if you are using the remote
protocol. It does not address gdb's debugging interface to simulators.
This is a huge deficiency in my opinion.

--Mark