Call Stack

Download pre-release library modules and new examples to use with Astrobe for Cortex-M. Forum members can also upload their own source code examples.
Post Reply
gray
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Call Stack

Post by gray » Tue Feb 12, 2019 7:30 am

If a run-time error occurs, or a user-trap is triggered, is it possible to get (print, or create/retrieve a data structure such as a linked list) the call stack, ie. the chain of procedure calls that resulted in the trap? Thanks.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Call Stack

Post by cfbsoftware » Tue Feb 12, 2019 1:08 pm

Currently only the location where the error occurred and the current value of the registers are displayed. Displaying the call stack is on our todo list for a future release. AFAIK It should just require some additional code in the Traps library module.

gray
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Re: Call Stack

Post by gray » Wed Feb 13, 2019 4:22 am

IMO, that would be a great addition to the debugging toolbox. The location of an error is a good start and mostly helpful for modules of your main controller-logic, but for library modules that are used from different locations, to know what calls lead to an error is crucial. I am also confident that an extension of Traps.mod, unwinding the stack and get the locations of the callers, would be pretty straight forward. I assume that the documentation of the compiler's mechanics for stack management (and related topics, such as the format of the '.ref' resource) is not public, right?

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Call Stack

Post by cfbsoftware » Wed Feb 13, 2019 11:01 am

Niklaus Wirth describes the compiler's mechanics for stack management in great detail in An Oberon Compiler for the ARM Processor which you can download from the Oberon page on his website.

The corresponding code generated by the Cortex-M3 code generator of the Astrobe Oberon compiler is effectively the same.

The .ref resource is very straightforward. It is just a resource file with a list of module names and start addresses. The source code of the procedure Traps.GetModname shows how to use the ResData facilties to return the name of the module which contains the code at a specified address. Ideally the debugging reference data would be extended to include procedure names and / or line numbers as well but in the absence of that, the address offsets in the assembly language listings that can be generated in the Professional Edition could be used to help pinpoint the error.

However, we have found the existing simply trap handler to be sufficient to identify most runtime errors in practice, particularly if assertions are used judiciously to validate input parameters to procedures etc. The real tricky problems are the ones that result in infinite loops and never generate a trap. I recall successfully using a watchdog-timer type of technique to diagnose these - I'll see if I can track that down so I can document it here as well.

Post Reply