[llvm-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang

Manoj Gupta via llvm-dev llvm-dev at lists.llvm.org
Mon May 14 12:11:41 PDT 2018


On Mon, May 14, 2018 at 12:07 PM Friedman, Eli <efriedma at codeaurora.org>
wrote:

> On 5/12/2018 9:23 PM, Philip Reames via llvm-dev wrote:
> > Fair warning, the following is a devil's advocate position, but it's
> > also a serious question.
> >
> > Given the entire point of this flag appears to be bug mitigation, why
> > not frame this as a sanitizer?  If we had a hypothetical
> > -fsanitize=dereference which tried to catch dereferenced pointers
> > derived from null, wouldn't that handle the case at hand?
>
> It's called "-fsanitize=null": it catches stuff like "x[3]" where x is
> null. It's not quite complete; we don't check for arithmetic on a null
> pointer.
>
> Yes, that would handle the situation in question, but putting implicit
> null checks all over the place is pretty expensive; I don't think most
> people would turn that on in production.
>
> -Eli
>

We had a similar discussion on an internal thread a while back if we can
use "-fsanitize=null" where clang
would generate ud2 instruction for null pointer dereferences.
Unfortunately, this doesn't work in kernel context.

Quoting the reply from our kernel team:

"It will not cause a kernel panic: it's an exception trigger, and it's
up to the exception handler to decide if it will return (WARN) or not
(BUG). In the referenced function, this is calling WARN_ON() which
will resume execution. (And note that the BUG() implementations are
specifically marked with __attribute__((noreturn)). "
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180514/5d8137d6/attachment.html>


More information about the llvm-dev mailing list