Traceback chain and LIB$I64_GET_CURR_INVO_CONTEXT

[Michael Moroney]

I'm using LIB$I64_GET_CURR_INVO_CONTEXT and LIB$I64_GET_PREV_INVO_CONTEXT to try to do some traceback in case of a fault, and I don't see how I can tell which frame corresponds to the routine that got the fault. So far, I've seen in a routine established by a condition handler, get_curr_invo_context returns the context corresponding to the condition handler itself, the next two frames are system space addresses, and the next one is _usually_ the one with the fault. I've also extracted the fault PC from the signal array and compared it to the libicb$ih_pc and if a match, it's the fault routine. But that doesn't seem to work for certain ACCVIOs. Am I missing a "Stop here!" bit in the frame chain?

Why no frame pointer on Itanium? The code I'm adapting is simpler.

[John Gillings]

Michael,

For some ACCVIOs the PC itself will be the ACCVIO address. Typically something like a call frame with a corrupted return address - you RET into garbage and therefore ACCVIO.

In that case I'd assume you'd want to report it against the caller (the one you didn't return to?), but I can't think of a simple, and totally general way to determine that frame. Similar situation with other branches into nowhere.

>Why no frame pointer on Itanium?

Architectural philosophy?

The simple VAX model where everything is always on the stack is great for programmers, but since that forces everything into references to real memory, it's not so good for performance.

The Alpha calling standard introduced null and register call frames to improve performance when routine calls don't have too much context to save and restore. No need to access memory. Of course, that makes life harder for debugging and makes error handling more complex because there are more combinations of possible call stacks and frames. At least Alpha retains an FP to help (even though it's sometimes "synthesized")

EPIC takes things even further, trying to keep even more context in registers and dispensing with the FP.

I guess the bottom line here is, things that make debugging easier tend to cost in terms of performance. When the trend is to faster and faster processors, programmers lose out! Be more more careful writing code>? ;-}

[Hoff]

If you're rummaging around with the invocation context to implement some sort of a traceback handler and related details for logging these errors, and not chasing a specific fault, there are options:

http://h71000.www7.hp.com/DOC/83final/4493/4493pro_070.html
http://h71000.www7.hp.com/wizard/wiz_5175.html

The former is documented, the latter is AFAIK not.

Itanium uses an unwind table to sort this stuff out, and not a frame pointer (FP) and the stack.

[Michael Moroney]

re ACCVIOs: Yes I was reminded pretty quickly about PC=address with accvio fault with the first version that looked for the fault PC = the pc in the frame to start the trace, and got a null traceback. Of course I'd want the info from the active frame and its callers in this case.

I am revisiting this code because I am trying to simplify things for less tech-savvy people and also since I got an infinite loop of some sort (repeated calls to LIB$I64_GET_PREV_INVO_CONTEXT didn't find the termination flag somehow) and another null trace.

This is a fairly generic traceback that has to do specific things beyond the system provided traceback.