lkml.org 
[lkml]   [2020]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 01/13] objtool: Remove CFI save/restore special case
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?

> 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.

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.

--
Josh

\
 
 \ /
  Last update: 2020-03-26 14:45    [W:0.112 / U:2.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site