Make current stack pointer available

[PhilippHaefele]

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 #2 (comment)

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 #2 (comment)

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 #2 (comment)

[malsyned]

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.

GDB generally tries to ensure that there's always a register alias called sp, regardless of architecture. Debugging GDB §10.14 Registers says:

GDB has four “standard” register names that are available (in expressions) on most machines—whenever they do not conflict with an architecture’s canonical mnemonics for registers. The register names $pc and $sp are used for the program counter register and the stack pointer.
[...]
Whenever possible, these four standard register names are available on your machine even though the machine has different canonical mnemonics, so long as there is no conflict. The info registers command shows the canonical names. For example, on the SPARC, info registers displays the processor status register as $psr but you can also refer to it as $ps

LLDB ensures an sp alias, too. I can't find any official documentation about it, but in the source it's pretty clear that they're also supporting $sp and other generic register names:

https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/lldb/include/lldb/lldb-defines.h#L57
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/lldb/source/Target/RegisterContext.cpp#L57
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/lldb/source/Utility/Args.cpp#L441
(see also git grep LLDB_REGNUM_GENERIC_SP)

Does this alias definitely not work on Xtensa for you?

The wrinkles to building on this that I see are:

• I don't know if every debugger you want to support permits the dollar-sign $sp syntax for register access in expressions. Are there actually any embedded debugging backends supported by VSCode that aren't just one wrapper or another around either GDB or LLDB?
• I don't know if every debugger you want to support provides an sp alias for the stack pointer.
• DAP will report the platform-specific mnemonics in register variable scopes, not the sp alias.

Maybe this needs a combination of

• GDB/LLDB $sp syntax
• DAP register scope introspection with a list of common synonyms (rsp, esp, usp)
• some enhancements to architecture detection to special-case csky (r14), microblaze (r1), xtensa (a1), and the few other architectures whose ABIs just use a generic register as the stack pointer

2. If we know the stack range, it should be within that range and we are done

Won't this make it harder to diagnose and troubleshoot stack overflows?

[haneefdm]

You can always test the expression $sp once to see if it fails.

But, I am still wary of the sp being examined while we stopped outside a task (in Kernel or ISR). @PhilippHaefele doesn't think so but I am not convinced for all OSes

[malsyned]

But, I am still wary of the sp being examined while we stopped outside a task (in Kernel or ISR). @PhilippHaefele doesn't think so but I am not convinced for all OSes

Is your concern that, by using $sp instead of pxTopOfStack, rtos-views will actually be more likely to give incorrect, misleading, or confusing results when the current task is paused in an ISR or SVC routine on architectures that a dedicated stack for IRQs?

I can sorta see the logic, at least for non-MPU ports. What you're seeing in pxTopOfStack is the value the stack pointer had at the most recent context switch, which is presumably not very old and likely to update frequently, just lagging behind a little bit.

With MPU ports, the problem is more serious. MPU ports use a dedicated system call stack for each non-privileged task. When the task voluntarily gives up the CPU, the actual user code stack pointer is backed up in pulTaskStack and ulContext contains a system call stack pointer. However, pulTaskStack gets zeroed out on return from system calls. So in my (our, now, I guess) current implementation, currently-running non-privileged tasks can get a "Stack Top" that points wayyyy outside of the task's stack.

I see how you would want to keep carefully weighing the pros and cons of examining $sp under most circumstances. @haneefdm @PhilippHaefele Would you be open to a minimal PR that just tried to use $sp on MPU tasks to work around this issue, without changing anything for non-MPU users?

[malsyned]

I got antsy and threw together a PR for the MPU-specific stuff.

[haneefdm]

I got antsy and threw together #73.

:-)