Quick overview of semantics

• call setjmp once, it can return twice
• first returns 0
• ... but stores machine state (register set) in the jmp_buf
• longjmp causes a non-local transfer of control - restores registers from jmp_buf, including stack pointer and program counter
• Control resumes at call site to setjmp, but now with the return value as specified by the longjmp call
• Can use this to direct code flow to exception path from longjmp non-local transfer
• Any stack storage used is recovered, but that's it - no destructors called

Dealing with cleanup: Maintain a runtime-stack of clean-ups and catch blocks

• try sets up an exception handling "frame" with a jmp_buf embedded in it
• Functions can push cleanup handlers onto the "current" frame
• throwing an exception runs cleanups, and eventually does longjmp

What's wrong with it?

Affects the happy path in two distinct ways:

• For any function, like g, we need to keep track of what we need to clean up
• For any catch block, we need to call setjmp, to get a copy of the machine state, and store it somewhere
• a jmp_buf is 200 bytes on amd64, 156 on i386

• At a specific point in the code of a function, the set of things we need to clean up is known at compile time.
• If we're in a try block, we know where the code for the associated catch block(s) are
• Therefore, we can store the info at compile time in a table, keyed by program counter
• This is the same data that any one function would have recorded with our SJLJ approach
• Pretty much 0 cost for the happy path
• May be quite expensive for the sad path - we'll look at what's involved

Our table-based approach only tells us what to do for the local function. How do we find out where we are in g() when h() throws an exception?

Use a register to point to the current stack frame: the "frame pointer"

On function entry push frame pointer, copy stack pointer to frame pointer, so new frame pointer points to old frame pointer

i386: ENTER and LEAVE instructions; use ebp for FP.

• As with SJLJ, we can build static tables, rather than doing work at runtime
• Saves instructions, stack space, and a machine register
• We have a table for each function, more or less
• Each row of our table says how to calculate the content of a register back in the function that called us.
• Includes two "special" registers/states
  • Call Frame Address - Takes place of frame pointer; Generally the stack pointer for the previous frame
  • Return Address Register (RAR) giving program counter in previous frame

Stack on entry to g: