Re: Python API for supplying thread information?

[Freddie Chopin <freddie_chopin at op dot pl>]

Hello Phil!

On Wed, 2017-03-22 at 15:37 +0000, Phil Muldoon wrote:
> Is it possible? Sure. But without looking at it in any real depth it
> would be a major undertaking. GDB does not have the concept of
> "Providers", it assembles state from many different sources: kernel,
> glibc, libthread_db etc.

Please note that for deeply embedded target these concepts don't apply
- there's no standard "kernel" (usually there's also no separation
between application and kernel), glibc is too huge and none of the
"standard" facilities. From what I've seen 

> This state is internally structured and
> relevant to GDB and is not really structured to receive arbitrary
> input from an API at the moment. It could, but I think it would
> require major surgery.

Well, the info OpenOCD provides to GDB is structured quite nice.
Basically OpenOCD just returns a list of tuples consisting of: thread
name (string), thread extra info (string, in most implementation it's
the info about state) and the thread ID (opaque value). Then it also
informs GDB which of these is currently active. GDB may also request
the list of thread registers, from what I understand by providing
"thread ID" and expecting a string with registers as hex.

All of that is done with GDB packets like "qThreadExtraInfo",
"qfThreadInfo", "qC" and some more.

In this case it would be enough to just get all that data with the
Python script instead of querying GDB server (OpenOCD).

> Currently the Scripting API is almost entirely focused with providing
> information and not really designed to take information. You have
> information providers APIs and data decorators APIs.

I might got something wrong, but wouldn't this be an example of
"information provider API"?

Regards,
FCh