Re: Python API for supplying thread information?

[Yao Qi <qiyaoltc at gmail dot com>]

Freddie Chopin <freddie_chopin@op.pl> writes:

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

The differences between "deeply embedded target" and PC doesn't matter
here.  As Phil said, GDB has to assemble state from different sources,
including OpenOCD and others.

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

OpenOCD can provide thread information because it embedded the RTOS
internal knowledge into it, as you mentioned in challenge #2 in your
first mail.  IMO, it is a pain.  In order to get rid of this pain
completely, python script is needed to *provide* thread information to
GDB by parsing some RTOS's data structures, so that OpenOCD don't need
these C code to get OS-specific thread information at all.  Providing
thread info isn't just printing thread name and state in "info
threads".  GDB internally needs thread information too.

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

I agree with Phil.  Some python APIs are needed to provide thread
information to GDB, but they are missing in GDB now.  Note that we are
working Linux kernel awareness debugging in GDB, in which we get Linux
specific information, for example, kernel threads, via C code.  We
thought about doing it in python two years ago, but decide to implement
it C first, and then, add needed python interfaces in GDB and move the
code to python if possible.

-- 
Yao (齐尧)