Messages in this thread | | | Date | Wed, 17 Jan 2018 08:30:21 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 06/10] objtool: Implement jump_assert for _static_cpu_has() |
| |
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
| |