Messages in this thread | | | Date | Thu, 26 Mar 2020 16:38:41 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v4 01/13] objtool: Remove CFI save/restore special case |
| |
On Thu, Mar 26, 2020 at 08:44:48AM -0500, Josh Poimboeuf wrote: > On Thu, Mar 26, 2020 at 01:58:44PM +0100, Peter Zijlstra wrote: > > So instr_begin() / instr_end() have this exact problem, but worse. Those > > actually do nest and I've ran into the following situation: > > > > if (cond1) { > > instr_begin(); > > // code1 > > instr_end(); > > } > > // code > > > > if (cond2) { > > instr_begin(); > > // code2 > > instr_end(); > > } > > // tail > > > > Where objtool then finds the path: !cond1, cond2, which ends up at code2 > > with 0, instead of 1. > > Hm, I don't see the nesting in this example, can you clarify?
Indeed no nesting here, but because they can nest we have that begin as +1, end as -1 and then we sum it over the code flow.
Then given that, the above, ends up as -1 + 1 in the !cond1,cond2 case, because that -1 escapes the cond1 block.
> > I've also seen: > > > > if (cond) { > > instr_begin(); > > // code1 > > instr_end(); > > } > > instr_begin(); > > // code2 > > instr_end(); > > > > Where instr_end() and instr_begin() merge onto the same instruction of > > code2 as a 0, and again code2 will issue a false warning. > > > > You can also not make objtool lift the end marker to the previous > > instruction, because then: > > > > if (cond1) { > > instr_begin(); > > if (cond2) { > > // code2 > > } > > instr_end(); > > } > > > > Suffers the reverse problem, instr_end() becomes part of the @cond2 > > block and cond1 grows a path that misses it entirely. > > > > So far I've not had any actual solution except adding a NOP to anchor > > the annotation on. > > Are you adding the NOP to the instr_end() annotation itself? Seems like > that would be the cleanest/easiest.
That actually generates a whole bunch of 'stupid' unreachable warnings. Also, in the hope of still coming up with something saner, we've been carrying a minimal set of explicit nop()s.
> Though it is sad that we have to change the code to make objtool happy > -- would be nice if we could come up with something less intrusive.
Very much yes, but so far that's been eluding me.
| |