> On 17 Mar 2017, at 11:48, Freddie Chopin <[email protected]> wrote: > > ... DRTM ... is asking for way to much > information. Unless I've forgotten about something now, OpenOCD needs > only: > - thread address, > - thread name, > - thread state, > - thread registers.
the actual DRTM code is not yet public, what you saw was an experimental version, now I have a functional version that works with J-Link. normally GDB does no ask state, priorities, etc, it asks for a description string, that is displayed "as-is", for example in Eclipse. so my code is not "asking" for too much information, is making the best use of extra available information. if this extra information is not available, it is obviously not displayed. for µOS++ I'll display thread state, priorities, and, if the system is configured with statistics, probably cpu usage in %, stack usage, and possible other things that might help during development. > Your code also asks for priority, inherited priority (a concept which > may as well be absent in an RTOS), child & parent threads (which may or > may not be supported at all). You also assume that there is a > "variable" which says whether a scheduler is started (another thing in > other RTOSes which I cannot really understand - why do they require you > to "start" it?). It also seems that in your project the threads are > arranged in a tree-like structure of lists, while I plan to only > support a single flat list for debug purposes. I'm afraid you got this wrong, I do not assume any of these for all systems, the implementation you saw was specific for µOS++. as for the variable to tell if the scheduler was started, the point is that at a certain moment during the initialisation the scheduler is started, either by the system or explicitly by the user. before the scheduler is started, GDB should behave as if multi-thread support is not yet available, i.e. display a single thread without any special description, do nothing special for reading/writing the registers from other context, etc. but, as I said, you got this wrong, it is not a super-standard, it is a solution to avoid hard-coding offsets and other data into debugging tools, and the first implementation is specific to µOS++ and J-Link, with support for OpenOCD to be added soon. if this is not of any value for you, please ignore the suggestion. regards, Liviu ------------------------------------------------------------------------------ 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
