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
