This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 unwind thoughts
On Fri, Feb 23, 2001 at 07:06:41PM +0000, Jason Merrill wrote:
> If there are no cleanups, we should give a null landing pad offset as well,
> since we don't need to return to the function.
So (@Start == @LPStart && LPad == 0) means keep unwinding?
How abort when @Start != @LPStart? How can a null landing
pad be represented there?
One could say that LPad must always have a non-zero value,
but I bet that's not what HP had in mind. Not that it
matters that much, given the other tweeks we'll be making.
> Except that would produce a call to unexpected(), which isn't right either.
Oh, that's right, no-throw is supposed to be terminate(), isn't it.
> BTW, weren't you planning to stick with PC ranges rather than specific call
> sites, anyway?
Yeah. It's too hard to genericly figure out where to put
(or fudge) the label. Particularly with targets like MIPS
where the jsr is a macro that expands to a whole series of
insns.
> >> The cleanups don't became handlers; call sites within the inlined function
> >> gain action records that refer to the handlers for the enclosing try
> >> blocks.
>
> > If there are no enclosing try blocks? Say if f1 got inlined
> > in the above example?
>
> Then they still have no action records.
They've got to have something. To clarify:
struct A { ~A(); };
int x;
void f1()
{
A a;
f2 ();
}
void f0()
{
f1 ();
try {
f2 ();
} catch(...) {
x++;
}
}
after inlining we have
f2(); // L1
a.~A();
f2(); // L2
R2:
return;
L1:
a.~A();
_Unwind_Resume;
L2:
x++;
goto R2;
So L1 is cleanup only, and L2 is a handler. As I read the
document, however, both get an action filter of 0.
There are four cases that we want to clearly distinguish:
(0) Can't throw.
(1) Can throw, no cleanup or handler this function.
(2) Can throw, only cleanup this function.
(3) Can throw, (...) handler.
r~