• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 346 subscribers
  • Views 7637 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to get Call Stack from stack data.

Mountain Mountain
Offline
Note: This was originally posted on 23rd January 2009 at http://forums.arm.com

Hi everyone.

   Here is a question that puzzled me a long time. if I get stack data(HEX data),  anyone konw that how to get call stack from it.

   How to know that which is R14.
  • 0 Offline
    Note: This was originally posted on 25th March 2009 at http://forums.arm.com

    Thank you for all your reply.

         Recently, I am studying a new platform,  when system crash, it can output all task stack data and also identify which is R14 in the stack data as the following:

    [color="#FF0000"] [0a0243fc/821933fc]=00003320  TCC_Task_Shell()           [/color]      
      [0a0243f8/821933f8]=00000000 
      [0a0243f4/821933f4]=00000000 
      [0a0243f0/821933f0]=00000000 
      [0a0243ec/821933ec]=00000000 
    [color="#FF0000"] [0a0243e8/821933e8]=0000332f  TCC_Task_Shell()                   call FuncPtr (Thumb BLX R0)[/color]  [0a0243e4/821933e4]=00000000 
      [0a0243e0/821933e0]=00000000 
      [0a0243dc/821933dc]=00000000 
      [0a0243d8/821933d8]=813085ec 
      [0a0243d4/821933d4]=000b4ba8 
      [0a0243d0/821933d0]=80eb4bd4 
      [0a0243cc/821933cc]=000b4ba8 
      [0a0243c8/821933c8]=00000001 
      [0a0243c4/821933c4]=00000000 
      [0a0243c0/821933c0]=00000000 
      [color="#FF0000"][0a0243bc/821933bc]=000000c0  TCT_Control_Interrupts()         
      [0a0243b8/821933b8]=8110bec7  capi2driverTask_Entry()            call(Thumb BL) CAPI2_HandleEvent()               [/color]  [0a0243b4/821933b4]=81372868 
      [0a0243b0/821933b0]=00000011 
      [0a0243ac/821933ac]=00000000 
      [0a0243a8/821933a8]=81905240 
      [0a0243a4/821933a4]=81905220 
    [color="#FF0000"] [0a0243a0/821933a0]=80f7849f  CAPI2_HandleEvent()                call(Thumb BL) CAPI2_DispatchMsg()               [/color]  [0a02439c/8219339c]=81372868 

      and the wonderful comments in the specification:

    [color="#FF0000"]  Red colored lines are the actual function call traces[/color] The others can be ignored (they are registers/parameters/
      local variables pushed into the stack when a function is called)


      How to implement it.

      Thank you very mcuh
  • 0 Offline
    Note: This was originally posted on 28th January 2009 at http://forums.arm.com

    Debuggers can do this for you from the code image (such as an .axf file if using RVCT). The image file contains debug information about what each function saves on the stack.

    For example, follow the link to the ARM Support Knowledgebase on these forum pages, and search for "call stack" to see RVD features for this.
  • 0 Offline
    Note: This was originally posted on 7th December 2009 at http://forums.arm.com

    Of course, this only works because C functions will be ABI compliant and thus don't mess up the stack pointer. If you write a function in assembly which doesn't correctly handle the stack pointer, everything will fall apart because what should be stored in r14 will end up somewhere else.
  • 0 Offline
    Note: This was originally posted on 28th January 2009 at http://forums.arm.com

    Interesting question.

    Basically, the stack works because you read values off it in the opposite order to that which they were stored. r14's entry in the stack will not be obviously labelled as such, for example.

    Of course, this only works because C functions will be ABI compliant and thus don't mess up the stack pointer. If you write a function in assembly which doesn't correctly handle the stack pointer, everything will fall apart because what should be stored in r14 will end up somewhere else.

    Also, note that there may be many copies of r14 in the stack as it will be pushed every time a function needs to modify it. As r14 is the link register, that will occur for pretty much every function call.

    The only way to determine where r14 is located in the stack is to study your code and work out the address at which it will eventually be stored. Of course, you can use a debugger to do that for you by setting breakpoints and that kind of thing.

    Does that answer your question?