<div dir="ltr"><div>I have asked about the constraints on LLVM sanitizers github. Waiting for their response. </div><div><br></div><div>If sanitizers is not possible, is only adding clang-analyzer too small a project for GSOC?</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 11:59 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> On 15/03/2020 17:52, suyash singh wrote:<br>
>><br>
>> Hello,<br>
>> Out of<br>
>> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and DataFlowSanitizer.<br>
>><br>
>> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers suggested?<br>
>><br>
>> Asking as part of my proposed gsoc project,<br>
>> <a href="https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing</a><br>
>><br>
>> 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.<br>
><br>
><br>
> +1<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> You need to check if any of these will work before this project has a chance.<br>
><br>
> I would be willing to entertain a project for an appropriate solution that is limited to say ARM, x86, and RISC-V.<br>
><br>
+1<br>
<br>
UBSan is a good candidate.<br>
<br>
> --joel<br>
><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>