OSDev.org

What do you mean by "no specific guarantee"? Doesn't gcc currently guarantee the exact semantics of those options, even if the disabling flags are not always described explicitly. But take "fno-defer-pop" for example, which is documented. It has strict meaning. Not like say, using "inline" specifier to a function definition. I am not questioning that these options may not be reliable for future use, but even the linux kernel uses "-fno-omit-frame-pointer" to get proper traces, and may be a few other things.

The subtle change didn't capture my attention. Yes, this will work better. Again, undeniably better solution then mine.

GCC does guarantee semantics of those options, at least for the current version. The problem is that the option you currently use does not guarantee what it thinks you guarantees. It only guarantees that ebp functions as the frame pointer. IT DOES NOT guarantee that gcc will actually use ebp to access local variables. If it thinks the resulting code might be more efficient using esp-relative accesses, it will use that as it wants. Hence, you are still not sure it will work correctly.

I cannot coerce it to fail at the moment, but your statement sounds correct. In other words, there is no way to perform alloca style adjustment to esp midway a C frame. Well, that is unfortunate. There are certain cases where this is convenient (such as dynamically performing stack realignment from C), and I was under the impression that it works, but apparently I got lucky. Looking at the glibc headers, I see that alloca is declared as __builtin_alloca, which explains how it manages to coerce the compiler to do what my use of this option is apparently not able to do. Thanks for the clarification to both of you.

P.S. To the OP if you are reading this. To keep the behavior stable, do remove the function attribute and use some of the other proposed solutions.