0

I see at the porting of threadx that in the top of each thread stack there are reserved uninitialized bytes, and then 16 zero bytes and just then the stack really begins.

The zero bytes called there backtrace. At the arm ports it is 4 bytes uninitialized and 4 zero (here for example), and at ARC porting both are 16 bytes sizes (here for example).

One more important thing is that the uninitialized bytes are initialized to 0xef if TX_DISABLE_STACK_FILLING isn't defined.

My questions are:

  1. Why there is a difference between ARC porting and ARM porting?
  2. Why those bytes exist? Is there is a trace tool or somthing in the algorithm that uses those bytes, or they are just for seeing in the memory 'by hands' that this memory didn't changed?
arye
  • 458
  • 3
  • 15

1 Answers1

1

Yes, the ARM and ARC ports are very different, i.e., different assembly code, pragmas, intrinsics, etc. It’s also noteworthy that different development tools are in play as well. For example, the main development tool for ARC is MetaWare (compiler/debugger), while on ARM there is IAR, ARM, GCC, etc.

As for stack backtrace, this is typically setup such that the debugger can create a call tree when there is a halt of execution or breakpoint in the current thread’s code. The backtrace byte pattern effectively represents the top of the stack and signals the debugger to stop building the call tree. Of course, this is every specific to the debugger and in this example the difference between the MetaWare debugger and the ARM tool debuggers. As for the 0xEF patter on the stack, this is useful for visual inspection by the developer. The pattern is also used by the run-time stack checking feature in ThreadX (please refer to the ThreadX User Guide documentation). Also, the IAR and MetaWare debuggers are able to calculate stack usage via examination of 0xEF pattern erosion in each thread’s stack and present that very useful information to the developer.

Stefan Wick MSFT
  • 13,600
  • 1
  • 32
  • 51