<div dir="ltr">Hi Gedare, Joel,<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> For clang support, I've made start by following the steps of [1]. I<br>
>> also have an industry contact (llvm/clang committer) who's willing to<br>
>> help me on that side of things. One question I have about this is, how<br>
> It would be most helpful if your contact would be willing to sign-up<br>
> in Google Melange as a mentor for RTEMS Project. Please have him/her<br>
> contact me directly for any clarifications.<br>
</span>+1<br></blockquote><div><br></div><div>I've sent a request on Melange. I'm mostly familiar with the llvm backend work, but I think I know (or can find out) enough about Clang to help Charith with his work (if he gets selected, of course).</div><div><br></div><div>Cheers,</div><div><br></div><div>- Asiri</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">>> do we define a success measure for this project? I mean, RTEMS seem to<br>
>> already compile with Clang with some local patches [1], but how do we<br>
> Somewhat true, but I believe there are problems with using clang that<br>
> have to do with the pervasive use of gcc spec files. A pre-requisite<br>
> task may be to get the spec files completely eliminated, which there<br>
</span>> is an ongoing effort to do with the "waf branch" of RTEMS [1ing tghe].<br>
I am suspicious that most of what is in the specs files is obsolete and<br>
already<br>
taken into account inside gcc by our rtems specific tweaks. GCC spec way<br>
extension is a way to accomplish things that can be done inside GCC but<br>
without modifying GCC source. The specs use predates us having many<br>
gcc tweaks.<br>
<br>
The short version is that a careful review may significantly reduce them.<br>
<br>
Also I have long had the idea that adding an option for an rtems bsp<br>
to gcc and clang could eliminate some needs also. The -B option is<br>
mostly to set an include and lib path to get the BSP.<br>
<br>
Random core dump of thoughts of unsure value.<br>
<span class="">> I think it makes the most sense to work from the waf branch and try to<br>
> help push it forward.<br>
</span>+1<br>
<span class="">>> evaluate whether the resulting binary is in good shape? should I also<br>
>> be thinking of some test-plan as part of the project? Secondly, will<br>
> RTEMS has an extensive test-suite [2], and you should be prepared to<br>
> run it before/after. We have a tool that helps with automation [3].<br>
><br>
>> it be OK if I fork off clang in github and maintain the patches there?<br>
>><br>
> Yes, we prefer for gsoc development to be done on github.<br>
><br>
>> I haven't yet tried out the RTEMS Eclipse plugin (on my TODO list),<br>
>> but I have an interest in learning Eclipse plugin development. I<br>
>> suppose the objectives of this project would be implement as much as<br>
>> possible in the TODO list of [2]?<br>
>><br>
> Yes, but some of those may be obsolete. Perhaps users will chime in<br>
> about what they would like to see in it.<br>
</span>Agreed. And suggesting Eclipse capabilities that are useful is welcomed.<br>
<span class="im HOEnZb">>> Many thanks for your comments.<br>
>><br>
>> - Charith<br>
>><br>
>> PS: "Hello World" exercise attached herewith.<br>
> Confirmed, thanks. Feel free to add yourself to the "Tracking Table" for 2015.<br>
><br>
> [1] <a href="https://git.rtems.org/amar/waf.git/" target="_blank">https://git.rtems.org/amar/waf.git/</a><br>
> [2] <a href="https://git.rtems.org/rtems/tree/testsuites" target="_blank">https://git.rtems.org/rtems/tree/testsuites</a><br>
> [3] <a href="https://git.rtems.org/rtems-tools/tree/tester" target="_blank">https://git.rtems.org/rtems-tools/tree/tester</a><br>
><br>
> Gedare<br>
><br>
>> [1] <a href="https://devel.rtems.org/wiki/Projects/CLANG" target="_blank">https://devel.rtems.org/wiki/Projects/CLANG</a><br>
>> [2] <a href="https://devel.rtems.org/wiki/Developer/Eclipse/Information" target="_blank">https://devel.rtems.org/wiki/Developer/Eclipse/Information</a><br>
>> [3] <a href="https://devel.rtems.org/wiki/GSoC/GettingStarted" target="_blank">https://devel.rtems.org/wiki/GSoC/GettingStarted</a><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>