Thanks for the pointer, Steven. This looks similar to what the current FreeRTOS code does. What happens when uCOS_III_get_thread_reg_list() is called with threadid=0? It looks like it's going to result in some memory reads, which doesn't make sense to me because there is no RTOS structure in memory at that point.
Tim On Wed, Feb 10, 2021 at 11:02 AM Steven Stallion <stall...@squareup.com> wrote: > I think my only worry is impact to other RTOSes. I had to hack around this > too when I wrote the uC/OS-III support. There's definitely a special case > when the RTOS is not running, but fortunately there's a variable I can > check for that at runtime. It might be worth taking a look at > src/rtos/uCOS-III.c:327 to see if that helps. > > Cheers, > Steve > > On Wed, Feb 10, 2021 at 12:54 PM Tim Newsome <t...@sifive.com> wrote: > >> I think the right solution is to modify the rtos_type API so that >> update_threads can return a special error indicating "no threads found." In >> that case rtos.c should automatically fall back to the hwthread rtos code, >> which simply exposes each core as a thread. On every call to >> rtos_update_threads(), first the configured rtos is called, so that that >> code will take over once code has advanced to the point where there are >> rtos threads. Does that make sense? >> >> Tim >> >> On Fri, Feb 5, 2021 at 1:48 PM Tim Newsome <t...@sifive.com> wrote: >> >>> I'm looking into adding RISC-V FreeRTOS support to OpenOCD, which means >>> I'm trying to understand how the OpenOCD FreeRTOS support works. >>> >>> The first thing I don't understand: >>> Before the program I'm debugging has created any >>> threads, uxCurrentNumberOfTasks is 0. So FreeRTOS_update_threads() creates >>> a dummy thread representing execution on hardware, and gives it threadid 1. >>> That seems pretty reasonable. >>> >>> But then in FreeRTOS_get_thread_reg_list(), the code tries to read the >>> stack pointer for this thread from the stack. That doesn't make any sense >>> for this special thread, which simply reflects the current execution >>> thread. It seems like this code should just read the regular registers for >>> this case. I don't see where that might be happening, though. How is this >>> supposed to work? >>> >>> Thank you, >>> Tim >>> >> _______________________________________________ >> OpenOCD-devel mailing list >> OpenOCD-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openocd-devel >> >
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel