On 3/24/2015 10:05 AM, Gedare Bloom wrote: > On Tue, Mar 24, 2015 at 10:52 AM, Charith Eranga > <eranga.char...@gmail.com> wrote: >> Hi All, >> >> I'm Charith Eranga from University of Moratuwa, Sri Lanka. I'm >> currently a second year student specializing in embedded software >> development. >> >> I'm particularly interested in compiling RTEMS with Clang [1] and the >> improvements to the Eclipse plugin [2]. I've made a start with RTEMS >> by compiling toolchain/rtems following the GSoC guide [3]. >> >> For clang support, I've made start by following the steps of [1]. I >> also have an industry contact (llvm/clang committer) who's willing to >> help me on that side of things. One question I have about this is, how > It would be most helpful if your contact would be willing to sign-up > in Google Melange as a mentor for RTEMS Project. Please have him/her > contact me directly for any clarifications. +1 >> do we define a success measure for this project? I mean, RTEMS seem to >> already compile with Clang with some local patches [1], but how do we > Somewhat true, but I believe there are problems with using clang that > have to do with the pervasive use of gcc spec files. A pre-requisite > task may be to get the spec files completely eliminated, which there > is an ongoing effort to do with the "waf branch" of RTEMS [1ing tghe]. I am suspicious that most of what is in the specs files is obsolete and already taken into account inside gcc by our rtems specific tweaks. GCC spec way extension is a way to accomplish things that can be done inside GCC but without modifying GCC source. The specs use predates us having many gcc tweaks.
The short version is that a careful review may significantly reduce them. Also I have long had the idea that adding an option for an rtems bsp to gcc and clang could eliminate some needs also. The -B option is mostly to set an include and lib path to get the BSP. Random core dump of thoughts of unsure value. > I think it makes the most sense to work from the waf branch and try to > help push it forward. +1 >> evaluate whether the resulting binary is in good shape? should I also >> be thinking of some test-plan as part of the project? Secondly, will > RTEMS has an extensive test-suite [2], and you should be prepared to > run it before/after. We have a tool that helps with automation [3]. > >> it be OK if I fork off clang in github and maintain the patches there? >> > Yes, we prefer for gsoc development to be done on github. > >> I haven't yet tried out the RTEMS Eclipse plugin (on my TODO list), >> but I have an interest in learning Eclipse plugin development. I >> suppose the objectives of this project would be implement as much as >> possible in the TODO list of [2]? >> > Yes, but some of those may be obsolete. Perhaps users will chime in > about what they would like to see in it. Agreed. And suggesting Eclipse capabilities that are useful is welcomed. >> Many thanks for your comments. >> >> - Charith >> >> PS: "Hello World" exercise attached herewith. > Confirmed, thanks. Feel free to add yourself to the "Tracking Table" for 2015. > > [1] https://git.rtems.org/amar/waf.git/ > [2] https://git.rtems.org/rtems/tree/testsuites > [3] https://git.rtems.org/rtems-tools/tree/tester > > Gedare > >> [1] https://devel.rtems.org/wiki/Projects/CLANG >> [2] https://devel.rtems.org/wiki/Developer/Eclipse/Information >> [3] https://devel.rtems.org/wiki/GSoC/GettingStarted >> >> _______________________________________________ >> 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 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
