Release candidate tool chain for 4.12

[Cillian O'Donnell]

On 27 July 2017 at 23:28, Chris Johns <chrisj at rtems.org> wrote:
> On 28/07/2017 00:40, Joel Sherrill wrote:
>> On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel