[cfe-dev] Reporting UBSan issues at compile-time

[Reid Kleckner via cfe-dev]

On Thu, Mar 23, 2017 at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> On Thu, Mar 23, 2017 at 10:45 AM Reid Kleckner <rnk at google.com> wrote:
>
>> I don't think it will be feasible to generalize UBSan's knowledge to the
>> static analyzer.
>>
>
> Why not? The rough idea I meant would be to express the constraints UBSan
> is checking into the static analyzer - I realize the current layering
> (UBSan being in Clang's IRGen) doesn't make that trivial/obvious, but it
> seems to me that the constraints could be shared in some way - with some
> work.
>

Maybe I am not imaginative enough, but I cannot envision a clean way to
express the conditions that trigger UB that is useful for both static
analysis and dynamic instrumentation. The best I can come up with is
AST-level instrumentation: synthesizing AST nodes that can be translated to
IR or used for analysis. That doesn't seem reasonable, so I think getting
ubsan into the static analyzer would end up duplicating the knowledge of
what conditions trigger UB.

The static analyzer CFG is also at best an approximation of the real CFG,
>> especially for C++.
>>
>
> Sure enough - and I believe some of the people working/caring about it
> would like to fix that. I think Manuel & Chandler have expressed the notion
> that the best way to do that would be to move to a world where the CFG is
> used for CodeGen, so it's a single/consistent source of truth.
>

Yes, we could do all that work, but LLVM's CFG today is already precise for
C++. If we allow ourselves to emit diagnostics from the middle-end, we can
save all that work.

Going down the high-effort path of extending the CFG and abstracting or
duplicating UBSan's checks as static analyses on that CFG would definitely
provide a better diagnostic experience, but it's worth re-examining
conventional wisdom and exploring alternatives first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170323/53211a99/attachment.html>