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
