On 14 March 2018 at 19:51, Cillian O'Donnell <cpodonne...@gmail.com> wrote:
> > > On 14 March 2018 at 18:26, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> > wrote: > >> I'm still getting the Covoar not found error >> I'm not able to understand what am I missing, if it needs a fix, please >> help me understand the code. >> > > Have a look where all the rsb tools were built. Does covoar appear in > there? > > The directory is something like: > > cd ~/development/rtems/4.12/bin > Sorry, nevermind that, just remenbered I had put covoar there for something else. You mentioned before that waf built covoar properly and it appeared in: "covoar is in /rtems-tools/build/covoar" is it this or is it rtems-tools/build/tester/covoar and you're definitely using the coverage-merge branch of my github https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge > >> Thanks >> >> On 9 March 2018 at 22:20, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> >> wrote: >> >>> >>> >>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" < >>> vijaykumar9...@gmail.com> wrote: >>> >>> >>> >>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" <joel.sherr...@gmail.com> >>> wrote: >>> >>> >>> >>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <cpodonne...@gmail.com >>> > wrote: >>> >>>> >>>> >>>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee < >>>> vijaykumar9...@gmail.com> wrote: >>>> >>>>> Hello sir, >>>>> >>>>> I need some guidance to proceed to apply for #2920 as my GSoC project. >>>>> >>>>> I wanted to know the following points : >>>>> >>>>> 1. What are the prerequisites (do I have to produce something ? like >>>>> the hello world ) >>>>> >>>> >>>> Other than the hello world, there's no official prerequisites. Usually >>>> the next thing is to fix a small bug, have a look at the tickets here: >>>> >>>> https://devel.rtems.org/query >>>> >>>> >>>>> 2. reference materials (like specific doc), to familiarise with the >>>>> rtems-tester and rsb . >>>>> >>>> >>>> Relevant to you would be RTEMS Tester section of the main user manual. >>>> The rest of the manual should be useful for setting up rtems in general. >>>> >>>> https://docs.rtems.org/branches/master/user/tools/tester.html >>>> >>> >>> Running this and submitting some results for a BSP on a simulator would >>> be a good step. >>> This project requires doing that a lot. You can do one BSP that runs on >>> a gdb based simulator >>> and another on a qemu based simulator. >>> >>> I'll surely do that . currently I'm trying to run cillian's project , >>> facing some issues with the test.py , which I'll try to fix , probably it's >>> related to the path . I'll be at the other part of the country for a few >>> days (4 days ), after that I'll try to submit results for a BSP on a >>> simulator >>> >>> There is a project based on qemu that includes coverage trace ability. >>> >>> >>>> >>>> The links to the previous projects which you already found and the >>>> other links I've mentioned. >>>> >>>> >>>>> 3. how to properly plan the project into phase wise tasks and weekly >>>>> sub-tasks. >>>>> >>>> >>>> Essentially it would be: >>>> 1. Get coverage analysis running again (converting the config files to >>>> .ini and a couple of fixes to some of the parsing in the sections that >>>> haven't been integrated, might be all that it takes). >>>> 2. Then get the coverage tools integrated with RTEMS Tester. Which is >>>> fix the outstanding issues that are mentioned in: >>>> https://devel.rtems.org/ticket/2920 >>>> Chris Johns might have things to add to this, ultimately the >>>> integration to RTEMS Tester will be up to him. >>>> >>> >>> I would add finishing getting the Couverture qemu into the RSB. >>> >>> Okay sir. >>> >>> >>> Once the setup is running, there are a couple of meaty projects. >>> >>> Chris and I have talked about reworking the report generation in covoar. >>> Currently, the C++ code writes HTML and txt files. It would be nice to >>> have covoar generate something which is subsequently processed >>> with a report generator. We don't have a complete solution in mind but >>> writing Sphinx like the RTEMS documentation is an option. One challenge >>> is that the current HTML output has filtering capability and that >>> wouldn't >>> be possible (I think) using Sphinx. >>> >>> The other desirable capability is to ensure the gcov output is correct >>> and >>> can be processed by the GNU gcov tool to produce reports with the same >>> results as covoar. I think Cillian got a start on this but only as far >>> as noting >>> it wasn't always the same. We have a mentor from the GCC community >>> to help with this. >>> >>> Once the gcov output is trustworthy, we can try other tools like lcov to >>> see what other reports we can get. >>> >>> >>> Thank you for describing the object in detail , I'll read more about >>> covoar and try to understand how it generates the output and how it can be >>> modified . >>> >>> >>>> The order in which the problems are listed in that ticket are probably >>>> the order in which you would complete them, the stuff about generating the >>>> xml reports and gcov and all of that is probably a 2nd or 3rd phase task >>>> for you depending on how it goes. The plan can change as you go along, its >>>> just important that you make a plan to begin with. >>>> >>>> Good luck, >>>> >>>> Cillian. >>>> >>>> >>>>> >>>>> Thank you, >>>>> Vijay k. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 1 March 2018 at 15:38, Cillian O'Donnell <cpodonne...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 1 March 2018 at 09:10, Vijay Kumar Banerjee < >>>>>> vijaykumar9...@gmail.com> wrote: >>>>>> >>>>>>> hello, >>>>>>> >>>>>>> while trying to figure out the starting point, I came across this >>>>>>> project form GSoC 2017 by C.P. O'Donell >>>>>>> >>>>>>> https://summerofcode.withgoogle.com/archive/2017/projects/49 >>>>>>> 25375616385024/ >>>>>>> >>>>>>> Is this the project that has previous works on the project I'm >>>>>>> wanting to take (#2920) ? If not , please help me find the right one. >>>>>>> >>>>>> >>>>>> Hi Vijay, >>>>>> >>>>>> Yes that's the one, let me know if you have any questions about it. >>>>>> When I checked last month coverage is not working with the RTEMS Tester >>>>>> because the configuration files for the bsps in rtems-tools/tester/rtems >>>>>> have been converted from .mc to .ini So the old .mc files I mention need >>>>>> to >>>>>> be converted before it will work again. >>>>>> >>>>>> This is what I wrote as the final documentation, it should help you >>>>>> reproduce what I had working last summer. >>>>>> >>>>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools >>>>>> >>>>>> Try this branch in github for the starting point: >>>>>> >>>>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge >>>>>> >>>>>> Good luck with the project, >>>>>> >>>>>> Cillian. >>>>>> >>>>>> >>>>>>> >>>>>>> Also, please guide me with reading references and some small tickets >>>>>>> related to the project . >>>>>>> >>>>>>> Thank you , >>>>>>> Vijay k. >>>>>>> >>>>>>> >>>>>>> On 26 February 2018 at 21:54, Vijay Kumar Banerjee < >>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>> >>>>>>>> Thank you for giving me a detailed introduction to the project >>>>>>>> objectives and mentors. >>>>>>>> I am interested in # 2920: "Improve Coverage analysis toolkit". >>>>>>>> >>>>>>>> Please guide me with the resources to get started with the project >>>>>>>> and get a deep understanding. >>>>>>>> >>>>>>>> Thank you >>>>>>>> Vijay >>>>>>>> >>>>>>>> On 26 February 2018 at 15:36, Joel Sherrill <j...@rtems.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 26, 2018 2:22 AM, "Christian Mauderer" < >>>>>>>>> christian.maude...@embedded-brains.de> wrote: >>>>>>>>> >>>>>>>>> Am 24.02.2018 um 16:21 schrieb Vijay Kumar Banerjee: >>>>>>>>> > Hello, >>>>>>>>> > >>>>>>>>> > As told by Joel, I sent the screenshots of my working hello >>>>>>>>> world to his >>>>>>>>> > personal email and have also included my name in the GSoC >>>>>>>>> tracking page . >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > + Make Eclipse Target Interaction work with RTEMS >>>>>>>>> > (https://www.eclipse.org/tcf/) >>>>>>>>> > + Improvements to our coverage reporting. GCOV validation and >>>>>>>>> covoar >>>>>>>>> > reporting improvements >>>>>>>>> > + wifi integration improvements >>>>>>>>> > + aarch64 port >>>>>>>>> > + x86_64 port / non-legacy PC BSP >>>>>>>>> > - This project is large so we would need to work with whoever >>>>>>>>> wants >>>>>>>>> > to tackle it >>>>>>>>> > to find the best subset for GSoC. >>>>>>>>> > >>>>>>>>> > Based on this list I went through the OpenProjects page >>>>>>>>> > and came across the following Tickets ., >>>>>>>>> > #2920 ,#3222,#2927 and the link to eclipse tcf . >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > out of them , I find these interesting >>>>>>>>> > 1. "Improve coverage Analysis Toolset " (#2920); >>>>>>>>> >>>>>>>>> >>>>>>>>> This area is mine. The ticket mat or may not be a great >>>>>>>>> description of the goals. There are probably three things that need >>>>>>>>> to be >>>>>>>>> done. >>>>>>>>> >>>>>>>>> + Integrate ran recipes for Couverture variant of qemu. This might >>>>>>>>> be a very small task. Last year's student just didn't get this >>>>>>>>> integrated >>>>>>>>> and was waiting for some patches to be merged on their side. >>>>>>>>> >>>>>>>>> + Verify the gcov output from covoar is correct and the gcov (and >>>>>>>>> similar tools) matches the coverage reports it generates. We have >>>>>>>>> someone >>>>>>>>> from the GCC community to help mentor here. >>>>>>>>> >>>>>>>>> + Covoar generates HTML and text output directly. There is a >>>>>>>>> desire for it to generate something equally useful that is processed >>>>>>>>> by >>>>>>>>> existing tools to generate reports. One possible option for this >>>>>>>>> output >>>>>>>>> could be Sphinx like our regular documentation. Or it could be a >>>>>>>>> data-centric format processed by other tools. The current HTML allows >>>>>>>>> filtering and sorting so not losing information and ease of use is >>>>>>>>> important. This probably will end up simplifying C++ and adding >>>>>>>>> Python. >>>>>>>>> >>>>>>>>> > 2. "libbsd:WiFi support needs rc.conf integration " (#3222) >>>>>>>>> >>>>>>>>> >>>>>>>>> Christian's project to mentor. >>>>>>>>> >>>>>>>>> > also I came across # 3302 :" Build system conversion of BSP >>>>>>>>> Config(.cfg) >>>>>>>>> > files to pkg-config(.pc) files" >>>>>>>>> > (I have some knowledge of Python, but not proficient in it, I >>>>>>>>> can learn >>>>>>>>> > it better if it's required ) >>>>>>>>> > which I find interesting >>>>>>>>> >>>>>>>>> >>>>>>>>> This one is Chris Johns project to mentor. It is an important and >>>>>>>>> logically the next step in replacing our build system with the Python >>>>>>>>> based >>>>>>>>> waf. If you get through this one before the summer is out, then >>>>>>>>> working on >>>>>>>>> waf would probably make sense. >>>>>>>>> >>>>>>>>> Did I miss one? >>>>>>>>> >>>>>>>>> Hello Vijay, >>>>>>>>> >>>>>>>>> all of the projects would be good ones. >>>>>>>>> >>>>>>>>> The #2920 and #3302 are more connected to the host tools. They >>>>>>>>> should be >>>>>>>>> doable with few or no real hardware. But you should ask the two >>>>>>>>> potential mentors about that. >>>>>>>>> >>>>>>>>> For the #3222 you would need some board supported by the libbsd >>>>>>>>> (like >>>>>>>>> Beagle Bone Black) and I would suggest a JTAG debugger (some >>>>>>>>> OpenOCD >>>>>>>>> based or similar). >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Am I following the right tickets? If not please help me find the >>>>>>>>> right ones. >>>>>>>>> >>>>>>>>> The tickets are the right ones. >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Out of these , which one do you recommend me to take ? >>>>>>>>> >>>>>>>>> I would recommend to take a more detailed look at the tickets and >>>>>>>>> start >>>>>>>>> to ask some questions about it on the mailing list with CC to the >>>>>>>>> (potential) mentors. >>>>>>>>> >>>>>>>>> Maybe you could also try to find some small tickets related to >>>>>>>>> similar >>>>>>>>> topics and just try to work on these. That could help you find out >>>>>>>>> what >>>>>>>>> you want to do. >>>>>>>>> >>>>>>>>> > My experience with C/C++ : I am proficient in C++11 with STL . >>>>>>>>> Also >>>>>>>>> > proficient in C language . >>>>>>>>> > My experience with opensource : This is the first open source >>>>>>>>> project >>>>>>>>> > I'm taking up . >>>>>>>>> >>>>>>>>> It's no problem if it's your first Open Source project. That's the >>>>>>>>> point >>>>>>>>> of GSoC: To collect first Open Source experience. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Christian Mauderer >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Thank you , >>>>>>>>> > Vijay K. >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -------------------------------------------- >>>>>>>>> embedded brains GmbH >>>>>>>>> Herr Christian Mauderer >>>>>>>>> Dornierstr. 4 >>>>>>>>> <https://maps.google.com/?q=Dornierstr.+4+%0D+D-82178+Puchheim+%0D+Germany&entry=gmail&source=g> >>>>>>>>> D-82178 Puchheim >>>>>>>>> Germany >>>>>>>>> email: christian.maude...@embedded-brains.de >>>>>>>>> Phone: +49-89-18 94 741 - 18 >>>>>>>>> Fax: +49-89-18 94 741 - 08 >>>>>>>>> PGP: Public key available on request. >>>>>>>>> >>>>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des >>>>>>>>> EHUG. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> >>> >>> >>> >>> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
