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 <ged...@rtems.org> wrote: > On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber < > sebastian.hu...@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@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
