rpc exception
Gregory M. Turner
gmturner007 at ameritech.net
Tue May 6 13:23:06 CDT 2003
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++. I figured out how VC++ does it: return does,
indeed, become a fancy unwind/jump sequence.
The more I think about this one the more discouraged I become... My idea of
stealing the return adress on the stack is also no good: by the time our
routine gets called, all the stack objects the __try {} block wants to refer
to are gone.
There might be some really clever trick involving manually creating simulated
stack frames, but I think it would require looking at data on the stack which
is deallocated... FWIW, it appears that vc++ does engage in some cheating of
a similar nature, violating the "Thou shalt not look beyond the top of the
stack" commandment.
btw ReactOS has a gcc patch for this:
http://reactos.wox.org/index.php?page=gccseh
they document several limitations there, so they aren't 100% done either, and
obviously, requiring compiler patches to build wine isn't going to improve
portability ;)
I think we have about three choices:
1) implement some really, really, really agressive stack mangling, and stick
with macros somehow.
2) implement a parser/generator of some kind to do it ourselves
3) focus on convincing the gcc dev's to put it in, and only use the feature in
wine if it's built into the compiler.
I don't like #3 and implementing #1 is looking pretty grim.
#1: so far nobody has thought of a way to do it; it's a dream, not a plan.
The possibilities we have explored, so far, would fail in g++ due to nested
functions, and break various other language features they aren't supposed to.
#3: not portable, and therefore not generally usable in wine.
That leaves #2. #2 could solve it for wine, ReactOS, anybody who wants it,
really. There are obviously certain hassles with another layer of parsing,
like slower compiles, making sure we don't break debugging, actually
implementing it, etc.
But I'm beginning to believe Alexandre that #1 is impossible (or at least
beyond the capabilities of my imagination) without more expressive power at
the language level.
--
"Security is mostly superstition. It does not exist in nature,
nor do the children of men as a whole experience it. Avoiding
danger is no safer in the long run than outright exposure. Life is
either a daring adventure, or nothing. To keep our faces toward
change and behave like free spirits in the presence of fate is
strength undefeatable." --Helen Keller
gmt
More information about the wine-devel
mailing list