Implementing try/catch as Macros

So this post has a couple of questions:

1. What does the stack look like when a signal is caught (via registering your own function with signal()). The reason that I ask is because I did a little assembly hacking to get the ebp register value and thus manually look through the stack, since the ra value is right after the ebp value. This works when I try it normally, its just when I try calling it from within the signal handler that i get really weird values. I tried looking them up via the nm utility but the range on the function ptrs all started with 4 whereas the values I was getting started with a 6.

2. So I was thinking that in macros in conjunction with signals would allow me to do the trick of a try catch type block. I could change catch to some random label and insert another random label after the catch. Then, i replace the try with a function call to set global variables with the location of the two previously mentioned labels and the current values of all the registers. Next, when the signal is caught, I replace all the values of the current registers with the saves versions and lastly goto the appropriate label (the catch block). Lastly, the macro would insert a goto finish label at the end of the try block so as to skip the catch block.

As far as what I dont know how to do in all that is two things. First, I dont know how to get the preprocessor to insert unique labels in the correct spots. Anyone know how? And secondly, I dont think that the signal handler can simply change the registers and jump since theres some state somewhere else that I need to unravel, right?

Any help with all of this is greatly appreciated,
chacham15

Things like stacks and registers are highly implementation-dependent and thus such questions cannot really be answered in a general fashion.

If you're looking to implement exceptions in C, setjmp() and longjmp() are the normal way:

Code:

---

#include <stdio.h>
#include <setjmp.h>

static jmp_buf exception_buf;
#define TRY if(setjmp(exception_buf) == 0)
#define CATCH else
#define THROW() longjmp(exception_buf, 1)

int main(void)
{
  TRY
  {
    puts("I am in a try block.");
    THROW();
    puts("I will not be seen.");
  }
  CATCH
  {
    puts("Exception caught.");
  }

  return 0;
}

---

This is, of course, about as basic as exception handling gets. You can get more fancy by longjmping with various values to get different exception types, but implementing this with macros would be tricky. You'd have to use a switch statement (I can't think of any other portable way) and getting that properly wrapped with a macro could prove ugly. But it's probably doable.

Addendum: An obvious way of handling multiple exception types would be to set a global variable (or, perhaps, push something onto a stack) before the longjmp. So you can easily avoid the need for a switch.

There. Let's see if this statement holds up. :)

The libpng library has a pretty nice try/catch macro set for use in C.

Is this the only bit of C++ you're interested in, or will you be looking to add aspects of "classes" later on?

The thing is that if I wanted to use a library, I'd be writing in C++ which is more suited for doing this kind of thing. I want to write my own version of this (as I have for printing out stack traces and such).

Now a few questions. I can kinda guess how the code you've added does the job but what happens if in the try block i do 1/0? Will that still work? If so, how does the code in the signal handler work? See, Im trying to implement my own versions of these things becuase I think that it gives me a greater understanding of whats actually going on (and its also fun!, but thats prob. just me). So if you could explain whats going on under the covers, so to speak, that would be helpful.

Secondly, I may want to add classes in the future (but, again, I want to implement that myself)

Thanks!
chacham15

You should be able to do longjmp from the signal handler.

Also consider that if you want to nest your TRY/CATCH blocks, then you need to track the current jump buffer, and restore to the previous one when leaving the current block - not sure how you go about doing that. Probably adding something in the CATCH macro to "restore to previous level".

--
Mats

So you want some kind of 'throw' from C code, which will become a C++ exception later on?

>So you want some kind of 'throw' from C code, which will become a C++ exception later on?

As a future goal, yes. But for now, i want it for some more mundane things:

For example,

Code:

---

BOOL isValidPointer(void *ptr, int size){
      char *temp = ptr;
      size = size - 1;
      try {
              while (size >= 0){
                      char c = *(temp+size);
                      size = size - 1;
              }
      } catch (exception e) { //even } catch { is ok for now
              return(FALSE);
      }
      return(TRUE);
}

---

but as far as trying to make the exception thrown compatible with anything else i dont care.

Thanks,
chacham15

Why don't you just write your code in C++? If you want to, you can only use exceptions, without using other features of C++. But even that would make your life easier than bashing the stack with longjmp() . . . .

But anyway. More about signals: http://www.cs.utah.edu/dept/old/texi...ibrary_21.html

I mostly do it for the experience. I feel that if you know how the tools you use work then you'll be able to use them better. Also, architecting complicated systems is fun.

How would you implement getting a stack trace from inside the signal handler? I've tried getting the base pointer then adding sizeof(void*) to get the return address and repeating but all I get are invalid pointers. Any ideas?

Are you accounting for local variables? If a function has local variables, those will go on the stack, too.

There must be a way to do this reasonably easily, but I don't know of it.

The stack is layed out in the following manner:

Base Pointer
Return Address
Stack Variables

So, yes. The interesting thing to note is that when I try to run the getStackTrace function from normal execution, it works perfectly. However, from a signal handeler, it doesnt. Why?

The only thing I can think of is this: a signal handler has to be called from somewhere. This code is probably low-level code in the kernel somewhere, and perhaps it doesn't follow the same stack layout that you expect from normal functions.

It's pretty far-fetched -- especially since most of the Linux kernel is written in C and I'm sure Windows isn't too different -- and it means that you should at least be able to read the stack for the signal handler itself.

Quote:

---

Originally Posted by dwks

The only thing I can think of is this: a signal handler has to be called from somewhere. This code is probably low-level code in the kernel somewhere, and perhaps it doesn't follow the same stack layout that you expect from normal functions.

It's pretty far-fetched -- especially since most of the Linux kernel is written in C and I'm sure Windows isn't too different -- and it means that you should at least be able to read the stack for the signal handler itself.

---

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

Code:

---

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.

--
Mats

Quote:

---

Originally Posted by matsp

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

Code:

---

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.

--
Mats

---

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

Thanks!
chacham15

> 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.

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