threadx 堆栈顶部的回溯的用途是什么？为什么它的大小会发生变化？
What is the usage of the backtrace at the top of threadx stacks and why it size varies?
我在 threadx 的移植中看到，在每个线程堆栈的顶部都有保留的未初始化字节，然后是 16 个零字节，然后堆栈才真正开始。
那里调用的零字节 backtrace。在 arm 端口，它有 4 个字节未初始化和 4 个零（例如 here for example), and at ARC porting both are 16 bytes sizes (here）。
更重要的是，如果未定义 TX_DISABLE_STACK_FILLING，未初始化的字节将被初始化为 0xef。
我的问题是：
- 为什么 ARC 移植和 ARM 移植之间存在差异？
- 为什么存在这些字节？算法中是否有使用这些字节的跟踪工具或其他东西，或者它们只是为了在内存中查看 'by hands' 此内存没有更改？
是的，ARM 和 ARC 端口非常不同，即不同的汇编代码、编译指示、内在函数等。同样值得注意的是，不同的开发工具也在发挥作用。比如ARC的主要开发工具是MetaWare(compiler/debugger)，而ARM上有IAR、ARM、GCC等
至于堆栈回溯，这通常是这样设置的，以便调试器可以在当前线程的代码中存在执行暂停或断点时创建调用树。回溯字节模式有效地表示堆栈的顶部，并向调试器发出停止构建调用树的信号。当然，这是每个特定于调试器的，在此示例中是 MetaWare 调试器和 ARM 工具调试器之间的区别。至于堆栈上的 0xEF 模式，这对于开发人员的视觉检查很有用。 ThreadX 中的 运行-time 堆栈检查功能也使用了该模式（请参阅 ThreadX 用户指南文档）。此外，IAR 和 MetaWare 调试器能够通过检查每个线程堆栈中的 0xEF 模式侵蚀来计算堆栈使用情况，并向开发人员提供非常有用的信息。
我在 threadx 的移植中看到，在每个线程堆栈的顶部都有保留的未初始化字节，然后是 16 个零字节，然后堆栈才真正开始。
那里调用的零字节 backtrace。在 arm 端口，它有 4 个字节未初始化和 4 个零（例如 here for example), and at ARC porting both are 16 bytes sizes (here）。
更重要的是，如果未定义 TX_DISABLE_STACK_FILLING，未初始化的字节将被初始化为 0xef。
我的问题是：
- 为什么 ARC 移植和 ARM 移植之间存在差异？
- 为什么存在这些字节？算法中是否有使用这些字节的跟踪工具或其他东西，或者它们只是为了在内存中查看 'by hands' 此内存没有更改？
是的，ARM 和 ARC 端口非常不同，即不同的汇编代码、编译指示、内在函数等。同样值得注意的是，不同的开发工具也在发挥作用。比如ARC的主要开发工具是MetaWare(compiler/debugger)，而ARM上有IAR、ARM、GCC等
至于堆栈回溯，这通常是这样设置的，以便调试器可以在当前线程的代码中存在执行暂停或断点时创建调用树。回溯字节模式有效地表示堆栈的顶部，并向调试器发出停止构建调用树的信号。当然，这是每个特定于调试器的，在此示例中是 MetaWare 调试器和 ARM 工具调试器之间的区别。至于堆栈上的 0xEF 模式，这对于开发人员的视觉检查很有用。 ThreadX 中的 运行-time 堆栈检查功能也使用了该模式（请参阅 ThreadX 用户指南文档）。此外，IAR 和 MetaWare 调试器能够通过检查每个线程堆栈中的 0xEF 模式侵蚀来计算堆栈使用情况，并向开发人员提供非常有用的信息。