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

[Freddie Chopin <freddie_chopin@op.pl>]

On Wed, 2017-03-22 at 18:51 +0100, Daniel Krebs wrote:
> Hi Freddie,
> 
> first of all, I feel the same way as you do. I'm one of those guys
> who
> have undergone the endeavour to add RTOS support to OpenOCD (in my
> case
> RIOT OS). All the problems (slow OpenOCD release cycle, hard-coded
> offsets/desynchronized information description, messy implementations
> in
> OpenOCD) you described are true, I only want to add another
> perspective.
> While trying to add support for RIOT, there was kind of a chicken-egg
> problem: without patches being merged in RIOT, you cannot test the
> OpenOCD implementation as well as the other way around when merging
> OpenOCD patches. Additionally, I've found it quite difficult to find
> people reviewing those patches on the OpenOCD side (it is not merged
> yet, I lost track of it). However, I totally understand that. Most of
> use are doing this in our free-time and so on, so I'd say this
> approach
> doesn't scale so well anyway.

Yes, that would be another issue with implementing such RTOS support.
It gets pretty hard when you have to modify both the RTOS and OpenOCD,
while _NOT_ being the developer of that RTOS.

I forgot about that, as I have the "luxury" of being the developer of
my own RTOS ( http://distortos.org/ ), so it's not a problem for me to
add any support for such integration with OpenOCD and/or GDB.
Especially because I see that as a thing of great importance!

> I have some experience with GDB Python scripting (there are also
> "new"
> OSes on x86), but I ran into the same problem as you did. To my
> knowledge (as of Dec 2016), there's no way to tell GDB about thread
> structures. That's why I ended up working around that by switching
> contexts myself. If it's of any help or interest to you, have a look
> at [1].
> 
> I'm not sure if it's possible for OpenOCD to add such support. It
> would
> make more sense to do that upstream in GDB IMHO, but it's the right
> direction. The upside of such an implemention is definetly that every
> project can manage these scripts in-tree and in sync with their
> development, with no dependency (as in providing patches) on OpenOCD
> anymore.

Exactly my thought - in that case the whole problem of "frozen" ABI is
just gone!

> Sadly, I cannot provide support on that matter at the moment because
> I'm
> lacking a use-case. Just wanted to add my 2 cents :)

Thanks for the input!

> Cheers,
> Daniel
> 
> 
> [1] https://github.com/RWTH-OS/HermitCore/tree/devel/usr/gdb

Regards,
FCh