On Wed, May 28, 2025 at 06:35:58PM +0200, Peter Zijlstra wrote: > On Wed, May 28, 2025 at 06:30:35PM +0200, Peter Zijlstra wrote: > > On Wed, May 28, 2025 at 09:44:52AM +0200, Peter Zijlstra wrote: > > > On Tue, May 06, 2025 at 12:18:49PM -0700, Josh Poimboeuf wrote: > > > > > > > Weird, I'm not seeing that. > > > > > > I Ate'nt Crazeh... > > > > > > https://lore.kernel.org/all/202505280410.2qfTQCRt-lkp@xxxxxxxxx/T/#u > > > > > > I'll go poke at it, see if today is the day I can figure out WTF > > > happens. > > > > It manages to trip the CFI_UNDEFINED case in op->dest.reg == cfa->base > > in update_cfi_state(). > > > > I figured it ought to tickle the regular 'mov %rbp, %rsp' case above > > there, but it doesn't, for some reason it has cfa.base == SP at this > > point. > > > > This happens... /me looks in scrollback ... at POP_REGS 'pop > > %rbp'. ARGH!! > > More fun! > > So the sequence of fail is: > > > > push %rbp > > mov %rsp, %rbp # cfa.base = BP > > > > SAVE sub $0x40,%rsp and $0xffffffffffffffc0,%rsp This hits the 'older GCC, drap with frame pointer' case in OP_SRC_AND. Which means we then hard rely on the frame pointer to get things right. However, per all the PUSH/POP_REGS nonsense, BP can get clobbered. Specifically the code between the CALL and POP %rbp below are up in the air. I don't think it can currently unwind properly there. > > ... > > push %rbp > > ... > > pop %rbp # cfa.base = SP > > This is the POP !drap and dest==base case. > > > ... > > mov %rbp, %rsp # UNDEF > > nop # FAIL > > RESTORE > > > > Note that the MOV+NOP is the 4 bytes ERETS needs.
