search

mcu-debug / rtos-views

RTOS views for microcontrollers
MIT License
24 stars 11 forks source link

Make current stack pointer available #28

Open PhilippHaefele opened 1 year ago

PhilippHaefele commented 1 year ago

Yup. For FreeRTOS, the Stack Top is definitely wrong. For current, I have a couple of options

  1. Depending on arch use $sp. For now, this works for both ARM, ARC, RISC-V. Even x86!! But not Xtensa -- it is $a1. Anyways, these are the architectures I run into.
  2. If we know the stack range, it should be within that range and we are done
  3. Else we may still be okay to use the $sp as if it is in Kernel code, there shouldn't be (mostly) a current-thread. The window of vulnerability is tiny
  4. We can figure this out if this becomes a problem that the stack top should be within a certain range of a user-specified limit or we would not use it.

Just thinking out loud

I will make a common function to get the current stack pointer that we all can use.

Originally posted by @haneefdm in https://github.com/mcu-debug/rtos-views/issues/2#issuecomment-1279767182

I would be very nice if we could get the actual stack usage of the current running thread, as it improves debugging stack issues a lot.

One more thing to consider is if the current execution is a interrupt/exception (mostly your point 3, but not sure what you mean exactly with kernel code), as they mostly use a dedicated system stack (initial stack pointer before start of OS). At least it's like that for uC/OS-II on Cortex-M processors.

When we implemented a uC/OS-II J-Link thread aware plugin we did this by checking the OSIntNesting variable of uC/OS and the NVIC VECTACTIVE bit. So we maybe also need a common function to test that that one.

Just my thoughts on this topic

@haneefdm Did you do anything regarding this topic until now?

Best regards

Originally posted by @PhilippHaefele in https://github.com/mcu-debug/rtos-views/issues/2#issuecomment-1382294390

Unfortunately, I have not had any time to look at this. By Kernel code meaning when you in the scheduler when it is about to swap out one thread with another. But this could include interrupt/exceptions

VECTACTIVE is a good idea but it is very ARM specific. I am expecting non-ARM clients as well. I will keep this in mind.

Originally posted by @haneefdm in https://github.com/mcu-debug/rtos-views/issues/2#issuecomment-1382876349