Getting stack-trace at run-time?

[Peter]

Hi,

is there any way to get a call-stack at run-time (on the target device, rather than gdb)? I want to display the call-stack on-screen on the target device when an assert takes places. I tried unwind.h without success as well as __builtin_frame_address which only supports one level of depth if I remember correctly.

How I can retrieve a call-stack at run-time? Basically it's completely fine for me when I can get a list with addresses of each function.

[elhobbs]

you can look at the defaultexceptionhandler code in libnds. you can usually find the previous function from the LR register. but, I am not sure how you would be able to automaticly interpret the stack without also loading/parsing the debug symbols.

[Peter]

you can look at the defaultexceptionhandler code in libnds. you can usually find the previous function from the LR register.

I'll take a look at! I hope it contains more than just LR, one call level is not really helpful. I'll see.

but, I am not sure how you would be able to automaticly interpret the stack without also loading/parsing the debug symbols.

I just need the address, resolving names shouldn't be a problem. Have done that 5 years ago for the Game Boy Advance already.

[elhobbs]

I was not suggesting that the debug symbols should be used for getting function names. I was saying that I thought that they were needed to correctly unwind the stack as I was under the impression that that the LR was pushed on the stack before a function call and its exact location was not always know since differences in function paramters can cause the stack to be different depthwise. I am not really an expert in this area though, but I thought the default exception handler would be a good place to start. good luck, please share results.

[Peter]

good luck, please share results.

Here they are: callstack trace on the nintendo ds

[bpoint]

Pretty impressive stuff. I've been pondering on adding support for getting a stack trace to my engine recently, but I certainly wouldn't have considered "semi-emulation" of the code.

Thanks for sharing!