Re: x86 entry perf unwinding failure (missing IRET_REGS annotation on stack switch?)

[Josh Poimboeuf]

On Tue, Apr 28, 2020 at 06:44:44PM +0200, Peter Zijlstra wrote:
> > > @@ -2494,8 +2494,16 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
> > >  				}
> > >  			}
> > >  
> > > -			if (skip_orig)
> > > +			if (skip_orig) {
> > > +				struct instruction *prev_insn = insn;
> > > +				sec_for_each_insn_continue(file, insn) {
> > > +					if (!insn->alt_group)
> > > +						break;
> > > +					if (!insn->visited)
> > > +						insn->cfi = prev_insn->cfi;
> > > +				}
> > >  				return 0;
> > > +			}
> > 
> > NACK :-)
> > 
> > What happens if you have two alternatives adjacent to each other (which
> > can definitely happen in this scenario)?
> 
> Alexandre's alt_group would help:
> 
>   20200414103618.12657-3-alexandre.chartre@xxxxxxxxxx
> 
> Then we can do something like:
> 
> static void fill_alternative(struct instruction *insn)
> {
> 	struct instruction *first_insn = insn;
> 	int alt_group = insn->alt_group;
> 
> 	sec_for_each_insn_continue(file, insn) {
> 		if (insn->alt_group != alt_group)
> 			break;
> 		if (!insn->visited)
> 			insn->cfi = first_insn->cfi;
> 	}
> }

Ugh...

> > I still like my patch, at least the hack is done before the validate
> > code, so validate_branch() itself is simpler.
> 
> But it doesn't handle the case where the alternatives themselves have
> unreachable holes in them, if that happens we'll generate spurious ORC
> entries for them.

Ah, I see what you mean.

I need to think about it...

-- 
Josh