What sanitizers preferred?

[suyash singh]

I have asked about the constraints on LLVM sanitizers github. Waiting for
their response.

If sanitizers is not possible, is only adding clang-analyzer too small a
project for GSOC?

If its too small there are several clang tools like thread safety analysis,
clang format and clang check which could be added. I don't know about their
usefulness in RTEMS.

On Mon, Mar 16, 2020 at 11:59 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>
> >> On 15/03/2020 17:52, suyash singh wrote:
> >>
> >> Hello,
> >> Out of
> >> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and
> DataFlowSanitizer.
> >>
> >> Are all of them useful as RTEMS-tools to integrate? Any other
> sanitizers suggested?
> >>
> >> Asking as part of my proposed gsoc project,
> >>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
> >>
> >> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
> >
> >
> > +1
> >
> > Another area is the compiler stack protection techniques. I have no idea
> if those are applicable to RTEMS but they would be useful if they can work.
> >
> > Ignoring other constraints from embedded systems, any possible technique
> to use with RTEMS must be evaluated against the constraints imposed by
> having a single address space, no VM, and single process model.
> >
> > You need to check if any of these will work before this project has a
> chance.
> >
> > I would be willing to entertain a project for an appropriate solution
> that is limited to say ARM, x86, and RISC-V.
> >
> +1
>
> UBSan is a good candidate.
>
> > --joel
> >
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200317/05771d25/attachment.html>