This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(179.20000000000002, 39%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
From the cortex-a9 readme_threadx.txt. When getting the tx_thread_stack_ptr I expect the frame pointer to
be at offset 0x34 or 0x24 from that address. However the offset to the frame pointer for the current
thread is actually 0x19C based on the value of the R11 register. This offset seems consistent when
checking the thread at tx_thread_ready_next as well. However when going to tx_thread_ready_next from that
thread, or tx_thread_created_next/tx_thread_created_prev from the original thread, that offset no longer
points to the frame pointer, in addition to 0x34/0x24 not pointing to the frame pointer. We do have VFP
register support enabled, but I do not see any documentation indicating that would affect the strack
frame. What is the actual correct way to determine the frame pointer location relative to
tx_thread_stack_ptr as the below offsets in the documentation are not valid. Thanks.
Offset Interrupted Stack Frame Non-Interrupt Stack Frame
0x00 1 0
0x04 CPSR CPSR
0x08 r0 (a1) r4 (v1)
0x0C r1 (a2) r5 (v2)
0x10 r2 (a3) r6 (v3)
0x14 r3 (a4) r7 (v4)
0x18 r4 (v1) r8 (v5)
0x1C r5 (v2) r9 (v6)
0x20 r6 (v3) r10 (v7)
0x24 r7 (v4) r11 (fp)
0x28 r8 (v5) r14 (lr)
0x2C r9 (v6)
0x30 r10 (v7)
0x34 r11 (fp)
0x38 r12 (ip)
0x3C r14 (lr)
0x40 PC
Hi @Ryan Greetings! Welcome to the Microsoft Q&A forum and thank you for posting this question. I have tried to find more information on the Register Usage and Stack Frames and here is what I have found in one of the GitHub repos.
Please note that the last statement in the above definition.
The top of the suspended thread's stack is pointed to by tx_thread_stack_ptr in the associated thread control block TX_THREAD.
It indicates that the tx__thread__stack_ptr points to the top of suspended thread's stack and it implies that this is bound to change when thread switches context.
Hope this provides some sort of clarity around this issue. Please let me know if you still need further clarification on this. I will follow with the SME's on this topic and can get more details on this.
Thanks for taking a look at my question. However, you appear to be looking at the incorrect readme document. Here is the text from the cortex-a9 version of the readme in the Github repo. If you could please have an SME follow up I would appreciate it.
The GNU compiler assumes that registers r0-r3 (a1-a4) and r12 (ip) are scratch
registers for each function. All other registers used by a C function must
be preserved by the function. ThreadX takes advantage of this in situations
where a context switch happens as a result of making a ThreadX service call
(which is itself a C function). In such cases, the saved context of a thread
is only the non-scratch registers.
The following defines the saved context stack frames for context switches
that occur as a result of interrupt handling or from thread-level API calls.
All suspended threads have one of these two types of stack frames. The top
of the suspended thread's stack is pointed to by tx_thread_stack_ptr in the
associated thread control block TX_THREAD.
Hi @Ryan thank you for your response. We have engaged with the SMEs on this topic and hoping to get some updates. Please stay tuned on this thread in the coming days for more updates.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(25.6, 6%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESA%3C/text%3E%3C/svg%3E)
Hi Ryan,
I'm not sure I understand your question. The contents of register R11 (FP) are saved at offset 0x34 or 0x24, but ThreadX does not care what those contents are. Are you seeing problems at runtime?
Hi Scott,
Thanks for your response. Looking at the attached screenshot, I see the tx_thread_stack_ptr at address 0x839C23E8. The offset 0x00 shows a value of 1, so I would expect the frame pointer at offset 0x34 or address 0x839C241C. However, as we see in the screenshot the value at that address is not correct for the frame pointer. I am not seeing problems at runtime. Just trying to understand how to get to the frame pointer for any thread when given the tx_thread_stack_ptr for that thread.
Hi Ryan, I think I am starting to understand your concern.
Two things off the top of my head: (1) that stack frame at 0x839C23E8 looks bizarre to me. The 1 and the CPSR look ok, but the all the GP registers have some very unique values in them, especially the LR and PC. What are the address ranges of your code and data regions?
(2) Where in the thread have you halted the debugger? The tx_thread_stack_ptr value contains the SP from the last time the thread context was saved. If this thread has since been running (and then you halt it), likely the SP has changed and whatever was previously in the saved stack has been overwritten.
Scott,
Hi Ryan, Is your code being built with frames? By default, the ARM ABI omits frame pointers, so R11 is just a general purpose register. https://developer.arm.com/documentation/100067/0607/armclang-Command-line-Options/-fomit-frame-pointer---fno-omit-frame-pointer
Hi Scott. Yes, we are using -mpoke-function-name and -fno-omit-frame-pointer. I've confirmed R11 correctly has the frame pointer in the executing thread and I am able to walk the stack back using it and save off the function names. My end goal is being able to do that for idle threads as well in addition to just the executing thread. That is why I'm trying to find the frame pointer relative to the tx_thread_stack_ptr.
Hi Ryan, another thing I just thought of - do you have TX_ENABLE_VFP_SUPPORT defined? If so, the VFP registers will be saved above the GP registers, so the thread stack will have the VFP registers between the CPSR and R0 (for interrupt stack) or R4 (for non-interrupted stack).
If you don't have VFP enabled, can you step through the code that does the context saving (https://github.com/azure-rtos/threadx/blob/master/ports/cortex_a9/gnu/src/tx_thread_system_return.S) and see where your frame pointer is actually being saved in the thread stack?
Yes, in my first post I did mention that we have VFP register support enabled because I thought that might be causing the issue, however I couldn't find any documentation indicating where that was inserted. Can you confirm the correct offset to the frame pointer would be 0x124 in that case? The original 0x24 offset + 0x100 for the 32 64-bit VFP registers. That offset seems reasonable for the frame pointer in the screenshot from my previous comment, 0x839E2E38+0x124 = 0x839E2F5C with a value of 0x8002296C. Looking at a different thread in the screenshot attached to this comment though, that offset does not seem valid. 0x81AD4B58 + 0x124 = 0x81AD4C7C with a value of 0x00000000. Are there any other defines that could affect the stack frame size? Is something causing that offset to be variable between non-interrupted threads? Or is 0x124 just not the correct offset?
I was able to figure it out looking at _tx_thread_system_return. D8 - D31 VFP registers plus the FPSCR register for a total of 0xC4. Combined with the original stack frame offset of 0x24 gives a total offset of 0xE8 to get the frame pointer. Edit: Actually, I'm not sure if this is actually solved yet. Hopefully on the right track, still investigating to confirm.
Hi Ryan, sorry I missed that originally. It sounds like you are on the right track! There will be different VFP registers saved depending on if it's an interrupt or non-interrupt context save. E.g. in tx_thread_system_return, D8-D31 are saved. In tx_thread_context_restore, D0-D31 are saved.