Back Trace Structures
The Back Trace Structure (BTS) chain is a feature provided by some Kernels and components to allow failures within the system to be diagnosed. Usually this is most useful during development, but it is envisaged that support will remain within the distributed release systems.
There are three categories of Kernel :
This document describes the side effects of the implementation of the BTS chain used by modern versions of RISC OS.
The SVC and IRQ stacks contain a word which is used to point to the head of the BTS chain. The SVC stack contains a word which is used as the head of the BTS chain itself. These words are stored at the base of the stack. This means that the 4 words at the base of the SVC and IRQ stacks are reserved for system purposes.
The use of these words on the SVC stack is as follows :
+0 APCS module C library static data offset
On the IRQ the use of the words is as follows :+0 Reserved
+8 Pointer to head of BTS chain +12 Reserved
Because BTS structures are stored within the stack, the amount of space used by routines will be changed. Most operations will be unaffected as the space requirements for BTS are not great compared to many component uses of the stack.
Similarly, the presence of BTS structures on the stack means that previous attempts to access data stored above the entry point on the stack, such as the SWI or IRQ entry parameters or similar, will fail. Such behaviour is strongly discouraged where it is reliant on internal behaviour within components which are outside the author's control.
Aside from following the path of control between components, the stack content above the entry should be considered private except where pointers are passed to structures which have been constructed upon the stack.
Chain and stack corruption
During the operation of the BTS system the operations will, where possible, check for corruption of the internal BTS structures. This is achieved by the 'return' from a BTS-active function checking that the head of the chain and the current stack pointer being the same. Where this is not the case there are 3 possible failures which could have taken place :
All 3 failures appear identical to the checks and will be reported in the same way. Under development versions of the Kernel, this was reported as a branch through zero. The failure is reported through an undefined instruction (&17FFFFFE) which is trapped by the Kernel undefined instruction handler. The undefined instruction handler converts this into a report that the system stack has become corrupt. It is reported as a hardware error, number &80000006.
This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.
HTML document version 1.03 3rd November 2015