It's been a while, but I believe there shouldn't be a case where threadid=0 when the RTOS is running. It was a convenient sleight of hand at the time, but I agree it would be nice if we had a more general facility for dealing with cases when RTOS support is configured, but not yet available.
On Wed, Feb 10, 2021 at 1:50 PM Tim Newsome <t...@sifive.com> wrote: > 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
