Re: [OpenOCD-devel] Python API for supplying thread information?

Hi,

I'm the guy who did the Infinity talk at Cauldron...

Freddie Chopin wrote:
> On Thu, 2017-03-23 at 10:23 +0100, Pierre-Marie de Rodat wrote:
> > What makes you think that? My understanding of the design is that
> > it's centered on adding new metadata sections to ELF binaries and
> > make the debugger use this metedata. This looks quite
> > embedded-friendly to me.
> 
> Maybe I got the wrong impression, sorry. But the problem is that
> this project doesn't seem very active... Generally fragmenting the
> effort (yet another library with yet another standard and so on...)
> doesn't seem like a very good idea to me, that's why in my opinion a
> solution implemented completely in GDB would be better suited and
> would have a higher chance of "survival" and "adoption". But I might
> got the wrong impression again.
> 
> However me and Liviu had a discussion about describing RTOS
> structure in a generic way and I'm still pretty certain that this is
> generally not possible in a generic and agnostic way. In the end it
> would become either extremely complex or you'd have to implement
> some kind of scripting/code to actually deal with that.

Infinity is active, but it's just me, and I've had some distractions
that've kept me from making progress of late.

I think it could do what you're asking.  I'm not super-familiar with
embedded systems but I assume you're using GDB talking to something
via the remote protocol?  Here's how I see it working:

* There's some information you need from the remote.  I'll use the
  example that you have a numeric thread ID and you want that
  thread's priority, which is also a number.

* You write an Infinity function, called thread::priority_for_ID or
  something.  That function gets compiled by the Infinity note
  compiler and lives in the executable.  Possibly in your case it
  would be stripped from the binary the embedded system sees, but
  present in the binary GDB sees.  [Note this is future work: Infinity
  functions are always unstripped at present.]  The function you wrote
  is basically things like "read this register, add this other thing
  to it, read this memory".

* GDB loads the binary, it has the Infinity functions.

* Your pretty printer is able to get the information it requires
  by calling the Infinity function you wrote via a Python API in
  GDB.  [Note again, this part is future work, there's no such API
  at present.]

* GDB executes the Infinity function you wrote, deferring to the
  remote for register and memory reads using existing remote protocol
  features.

This can all be done without adding extra features to the remote--the
Infinity function is executed by GDB.

It's not something that's weeks away from release, but if you want to
lend a hand? ;)

Cheers,
Gary
  
-- 
https://gbenson.net/