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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
