rpc exception

[Ove Kaaven]

tir, 06.05.2003 kl. 20.23 skrev Gregory M. Turner:
> On Monday 05 May 2003 07:28 pm, Ove Kaaven wrote:
> > tir, 06.05.2003 kl. 01.01 skrev Alexandre Julliard:
> > > Ove Kaaven <ovek at arcticnet.no> writes:
> > > > Hmm. That could be solved by making the try block a nested function
> > > > too, but I suppose that would bring some overhead...
> > >
> > > Even ignoring the overhead, I can't think of a way to declare that
> > > function with the right return type. But maybe I missed something...
> >
> > Hmm, true. I thought it might be possible to do some magic like
> > typeof(func()), but then you'd need to know the name of the function,
> > and I can't seem to find a gcc builtin that'll retrieve a reference to
> > the current function (or its return type). Anyone else have any ideas?
> > (No, __FUNCTION__ is a string, so it's no good.)
> 
> hmm, that sucks... there are some fancy __builtin_apply and __builtin_return 
> thingys in gcc, not sure if those would help or not, they look like a bit of 
> a research project in-and-of-themselves.
> 
> Of course, by using nested functions, this trick would limit our 
> implementation to gcc, no g++.

Maybe this particular implementation, but C++ has other mechanisms that
can be exploited. It might even be possible to bolt it on C++ native
exceptions. If not, return could be caught by e.g. using a temporary
object created in the try block which automatically unwinds the stack
when it's destroyed unexpectedly. C++ is so rich that it shouldn't be
hard to come up with such a technique, which is why I mostly concern
myself with C-specific techniques right now, and don't care about they
not working with g++; it should be completely acceptable to have one
implementation if __cplusplus is defined and another if not, as long as
it works, we don't have to limit ourselves to one implementation for
both if it's impossible to have one that way.

Apart from the ugliness, what was wrong with hijacking the return
address? It might be possible to put into the TEB any data you need that
you expect will go out of scope by the time the hijacker-function gets
invoked, I think.