On 27 July 2017 at 23:28, Chris Johns <chr...@rtems.org> wrote: > On 28/07/2017 00:40, Joel Sherrill wrote: >> On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de >> <mailto:sebastian.hu...@embedded-brains.de>> >> wrote: >> >> Hallo, >> >> the GCC 7.2 release will be probably in two weeks. I would like to use >> GCC >> 7.2 and the Newlib snapshot 2017-07-20 for the RTEMS 4.12 release >> candidate. >> I propose to do the 4.12 branch one week after the tool chain update. > > I do not think we are ready for a branch. I think a definite plan would help > identify what we want to complete and create a focus. > >> I don't mind bumping binutils and gcc. For now, that newlib snapshot is OK >> but I >> think we may want to bump to a newer one to catch the added POSIX methods >> from >> Aditya. > > Agree plus we *cannot* branch until we have a build on Windows. I do not want > to > have to work on a branch again to complete that task. > > We also need a bit of time after an update of the tools for testing. A week is > tight for me. > >> What concerns me is: https://devel.rtems.org/milestone/4.12.0 which still >> shows >> 80 tickets and I still don't think there is one describing the x86 breakage >> on >> libbsd. I have no idea how many of those should be addressed. These should be >> evaluated rather than just kicked down the road. > > Agreed. > >> I did a build sweep with fresh tools yesterday. All BSPs built in my >> configuration and the warnings are in OK shape. I have filed some tickets >> about >> a few but most of these are very easy to fix for the right person. Here are >> some >> areas by person who could fix quickly. Out of 57 unique warnings: >> >> + 12 are in libdebugger(Chris) > > I have a patch for libdebugger I am still testing. > >> + 6-8 are in BSPs or termios that I think you need to look at. >> + 7 are in new mmap code (Gedare)> >> It would be great if the core developers could take a look at the full report >> and see what can be eliminated >> >> ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170726/ >> >> There are somie warnings for the static asserts. I suspect these are due to >> BSPs >> are low optimization levels. >> >> So I would like to make sure we: >> >> + know the state of all tickets and consciously make a decision on them. >> + address some of these warnings. > + Windows build of tools. > + docs.rtems.org updated to work with repo updates and releases. > + Zynq PCAP patches from Patrick which are on the list > + examples-v2 building > >> That doesn't begin to address whether BSPs work or odd issues like do we >> switch >> to Couverture for qemu. > > What is the status of GSoC work? What are we looking at having merged onto > master?
I've been using my Couverture-qemu RSB build for about a month now. The patches have been sitting ready to go, I was just waiting to see if the Gaisler patches for leon3 get merged into upstream Qemu, but it looks as if they will, I just need to keep in contact with the Couverture guys. Couverture-QEMU works well for Leon 3, zynq-a9 and realview-pbx-a9. Other supported BSPS could just be a question of not having found the right qemu options, I haven't been able to chase that up further yet as I've been focusing on the coverage analysis tools. I can send the patches on now if anyone wants to take a look. > >> >> I'm not trying to be an impediment. I just want a burn down list. >> > > As you say a review of the tickets on the 4.12.0 milestone would be good. This > can then become the list of tasks we need to complete. > > Chris > _______________________________________________ > 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
