Thread: Implementing try/catch as Macros

  1. #16
    Registered User
    Join Date
    Jul 2008
    Quote Originally Posted by matsp View Post
    Although in Linux at the very least, the "base-pointer" (that is, frame-pointer) is excplicitly optimized away with -fomit-frame-pointer when compiling the kernel - so if you expect the format of
    Base Pointer
    Return Address
    Stack Variables
    then the first part will not (always - the compiler may still generate frame pointer code if it determines that frame-pointer makes better code [which is decided by heuristics - not a precise scientific decision]) be present.


    How would I then unwind the stack to get my trace?


  2. #17
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    > 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.

  3. #18
    Registered User
    Join Date
    Jul 2008
    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?

  4. #19
    Kernel hacker
    Join Date
    Jul 2007
    Farncombe, Surrey, England
    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).

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Order of execution of preprocessor macros
    By DL1 in forum C Programming
    Replies: 2
    Last Post: 04-02-2009, 06:52 PM
  2. parameterized macros vs. functions
    By Tbrez in forum C Programming
    Replies: 3
    Last Post: 04-02-2009, 12:33 PM
  3. function definition with macros
    By toshog in forum C++ Programming
    Replies: 2
    Last Post: 03-08-2009, 09:22 PM
  4. Macros inside of macros
    By Chewie8 in forum C Programming
    Replies: 2
    Last Post: 02-24-2008, 03:51 AM
  5. Macros vs Inline Functions
    By vb.bajpai in forum C Programming
    Replies: 4
    Last Post: 08-02-2007, 11:51 AM

Tags for this Thread