This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: PR 19225
- From: James E Wilson <wilson at specifixinc dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 24 Mar 2005 12:35:08 -0800
- Subject: Re: RFA: PR 19225
- References: <61b7b17ade67b2894047ae21383b94c9@apple.com>
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when it gets back to the landing pad?
There is no direct relationship between the two SP values. If they are
different, then there should be unwind info indicating the difference,
and the unwinder should be applying those differences while unwinding.
There is a statement to this effect in comment #3 from Andrew.
However, looking at this, I am tempted to call it a bug in the defer pop
optimization. The testcase works with -fno-defer-pop. This is
something we only do for old and/or embedded targets that push/pop
function arguments, so it wouldn't be noticable on most any system that
a gcc developer would be using. It is probably much easier to fix the
defer pop optimization than to fix the unwinder to handle this. An
unwinder fix would allow us to keep this optimization though.
Perhaps adding something to expand_calls like
/* ??? Defer pop and unwinding don't work well together. */
if (flag_exceptions && ! (flags & ECF_NOTHROW))
NO_DEFER_POP;
along with a corresponding OK_DEFER_POP later.
Actually, looking at this, I am surprised how may NO_DEFER_POP calls we
have without corresponding OK_DEFER_POP calls. I wonder if this
optimization is already broken, in the sense that is it being
accidentally disabled when it shouldn't be. Or maybe the code is just
more obtuse than it needs to be.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com