Thread: Implementing try/catch as Macros

> How would I then unwind the stack to get my trace?
Like the manual says, -fomit-frame-pointer makes debugging impossible, which would also make it impossible for you to follow the stack chain yourself.

The problem with stack-unwinding (which is the name of "how do I find out how to get back to where I came from") is that if you haven't got a frame-pointer, you do not know where the return address is without knowing at each instruction how much data has been pushed onto the stack. You could find that out by scanning the code, and based on where your exception happened, find the number of stack manipulations [push, pop, add/sub with stack pointer as target], but it is no easy task - you would have to know the length of each instruction, and then know which variants of instructions affect the stack [and how]. At least in x86, that would be pretty hairy to figure out, because aside from the obvious ones, one could consider:
lea esp, [esp + 8]
instead of:
add esp, 8
just to give one example.

This is why C++ compilers generate special tables that the application uses for stack-unwinding (sometimes combined with debug information that the debugger can use, for exampel x86-64, I think, uses DWARF2 for the unwind information as well as for debug information).

--
Mats