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

[Freddie Chopin <freddie_chopin at op dot pl>]

On Thu, 2017-03-23 at 12:38 -0500, Steven Stallion wrote:
> 
> On Thu, Mar 23, 2017 at 11:56 AM, Freddie Chopin <freddie_chopin@op.p
> l> wrote:
> > 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!
> > 
> 
> Why do you need to modify your RTOS? If this is a case where you need
> additional information at runtime, take a look under contrib at the
> RTOS helpers for FreeRTOS and uC/OS-III. This should give you an idea
> of how you can supplement the image under test with information you
> need for transient information like struct offsets. You have
> unfettered access to memory, so there's nothing holding you back or
> requires you to alter the RTOS source code.

It's not that I "need" to. I was just referring to the chicken-egg
problem mentioned earlier - if you are a "third party" (not OpenOCD
developer, not the developer of the RTOS in question), then just adding
these structures with RTOS mapping to the RTOS repository may pose a
problem. I know that these can be put into contrib/ folder of OpenOCD,
but I'm pretty certain that it's much better if such structs are part
of the main RTOS repository, which allows them to be maintained and "in
sync".

Regards,
FCh