On Tue, May 06, 2025 at 03:32:34PM +0200, Peter Zijlstra wrote:

On Tue, May 06, 2025 at 09:31:00AM +0200, Peter Zijlstra wrote:

quoted

On Sat, May 03, 2025 at 11:28:37AM -0700, Josh Poimboeuf wrote:

quoted

Can we just adjust the stack in the alternative?

	ALTERNATIVE "add $64 %rsp", __stringify(ERETS), X86_FEATURE_FRED

Yes, that should work. 

Nope, it needs to be "mov %rbp, %rsp". Because that is the actual rsp
value after ERETS-to-self.

quoted

But I wanted to have a poke at objtool, so it
will properly complain about the mistake first.

So a metric ton of fail here :/

The biggest problem is the UNWIND_HINT_RESTORE right after the
alternative. This ensures that objtool thinks all paths through the
alternative end up with the same stack. And hence won't actually
complain.

Right, that's what the unwind hints are made for, it's up to the human
to get it right.

Second being of course, that in order to get IRET and co correct, we'd
need far more of an emulator.

At least finding RSP should be pretty easy, it's at a known location on
the stack.  We already have an ORC type for doing that, but that would
again require an unwind hint, unless we make objtool smart enough to
know that.  But then the ORC would be inconsistent between the two
alternative paths.

Also, it actually chokes on this variant, and I've not yet figured out
why. Whatever state should be created by that mov, the restore hint
should wipe it all. But still the ORC generation bails with unknown base
reg -1.

Weird, I'm not seeing that.

-- 
Josh