Re: [PATCH v2 06/10] objtool: Implement jump_assert for _static_cpu_has()

[Josh Poimboeuf]

On Wed, Jan 17, 2018 at 08:27:59AM -0600, Josh Poimboeuf wrote:
> > > > +			if (insn->jump_dest == fake_jump) {
> > > > +				WARN_FUNC("jump inside alternative for _static_cpu_has()",
> > > > +					  insn->sec, insn->offset);
> > > > +			}
> > > 
> > > The error message doesn't seem to match the condition, so I'm not sure
> > > which one you're trying to check, or why.
> > > 
> > > IIRC, 'insn->jump_dest == fake_jump' means we reached the end of the
> > > alternative code block without hitting a jump.
> > > 
> > > But based on the loop exit condition, I don't think it's ever possible
> > > for insn->jump_dest to ever point to the fake_jump at the end.
> > 
> > Oof, now what was I thinking again.. So that fake_jump is inserted at
> > the end of the alternative and jumps to the code after where the
> > alternative will be patched in to simulate the code flow.
> > 
> > If there is a jump inside the alternative that jumps to the end, it's
> > destination will be set to the fake jump, we have this clause for that:
> > 
> > 	dest_off = insn->offset + insn->len + insn->immediate;
> > 	if (dest_off == special_alt->new_off + special_alt->new_len)
> > 		insn->jump_dest = fake_jump;
> > 
> > if that happens for static_cpu_has(), bad things happened.
> > 
> > So the only way for a jump to have fake_jump as destination is if the
> > jump is inside the alternative (but to the end) and we must assert this
> > didn't happen.
> > 
> > Unlikely, yes, but I figured we want to know about it if it ever does
> > happen.

So the case you're worried about, is it an unconditional jump?  As that
would be the only possibility based on the other warning.

-- 
Josh