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.
Actually I wrote that comment. While I see that it could be done that way
in the unwinder, I found no code that was actually trying to do it. So
I was unclear about the intent.
However, looking at this, I am tempted to call it a bug in the defer pop
optimization. ...It is probably much easier to fix the defer pop optimization
than to fix the unwinder to handle this.
I had tentatively reached this conclusion also, more slowly I'm sure.
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.
No, I think you are right, I'll see if I can clean things up without breaking it.
Thanks for your comments.
