> 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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Longjump can return me to my code from that. Does it just remember the register state and restore it? So does this mean that functions with this option cannot return? Because if they can, then theoretically I could follow that, right?
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.