[ubsan] nonnull and returns_nonnull sanitization

[Alexey Samsonov]

On Mon, Sep 1, 2014 at 2:36 AM, Jakub Jelinek <jakub at redhat.com> wrote:

> On Wed, Aug 27, 2014 at 11:23:54PM -0700, Alexey Samsonov wrote:
> > Ok, looks like I wasn't updating this thread for a while, sorry about
> that.
> > The current status is:
> > -fsanitize=returns-nonnull-attribute is implemented in Clang trunk
> > -fsanitize=nonnull-attribute is now being reviewed (
> > http://reviews.llvm.org/D5082). There were delays here due to numerous
> > problems with __attribute__((nonnull)) implementation in Clang and
> > uncertainties about nonnull semantic:
> >
> >   __attribute__((nonnull)) void foo(int a, ...);
> >   void call_foo() { foo(42, (void*)0); }  //should we report error in
> this
> > case? Probably yes, as GCC prints compile-time warning here.
>
> I'd say so, that is what the GCC documentation says for nonnull without
> arguments.
>
> > Now, the question is about the __ubsan_handle_nonnull_arg parameters.
> > Originally you proposed, to pass SourceLocation of a call in static data
> > and argument index in dynamic data (to be able to merge locations).
> > However, I think the error reports can benefit if we:
> > 1) pinpoint the location of a specific argument that incorrectly
> evaluates
> > to NULL.
> > 2) print the location of a function declaration which contains the
> nonnull
> > attribute.
>
> IMHO that is too big data size price for the limited benefit, locus of
> function call and argument number already uniquely identifies where the bug
> is.  But if you feel too strongly about it, do whatever you prefer on the
> clang/compiler-rt side and I'll need to adjust my GCC patch anyway, at
> least
> for the new names of the -fsanitize= arguments.
>

OK. I've submitted the patches to Clang and UBSan runtime which implement
-fsanitize=nonnull-attribute and -fsanitize=returns-nonnull-attribute (the
last
commit is r217400). I've added source locations of attribute declarations to
the static data passed in UBSan handlers to print them in the error
reports: it makes
sense to actually show user the declaration which forbids passing/returning
null pointer.
This location is also added to returns-nonull attribute, because the
attribute might be
declared far from the actual function definition with incorrect
return-statement.


>
>         Jakub
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140908/63f09c76/attachment.html>