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

Previous Topic Next Topic
classic Classic list List threaded Threaded
41 messages Options
Reply | Threaded
Open this post in threaded view

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

Jonathan Smith via llvm-dev
On 5/14/2018 12:11 PM, Manoj Gupta wrote:

On Mon, May 14, 2018 at 12:07 PM Friedman, Eli <[hidden email]> 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

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.


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

If the kernel can't use -fsanitize-trap, it could use some alternative like "-fsanitize=null -fno-sanitize-recover=null -fsanitize-minimal-runtime".  That doesn't seem like a fundamental flaw in the approach.


Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

LLVM Developers mailing list
[hidden email]