GCC Version Questions

[Chris Johns]

On 29/04/12 7:45 PM, Thomas Doerfler wrote:
> Chris,
>
> Am 29.04.2012 03:52, schrieb Chris Johns:
>> On 28/04/12 6:18 PM, Thomas Doerfler wrote:
>>> Hi,
>>>
>>> Am 28.04.2012 05:57, schrieb Ralf Corsepius:
>>>> On 04/27/2012 04:00 PM, Sebastian Huber wrote:
>>>>> I would rather use GCC 4.6.X for the RTEMS 4.11 release on ARM since I
>>>>> had a lot of trouble with earlier version of GCC 4.6. I worked with GCC
>>>>> 4.6 during the whole 4.11 development cycle and I am really at
>>>>> unease to
>>>>> use an untested GCC 4.7 for this release.
>>>>
>>>> Sebastian,
>>>>
>>>> a) rtems4.11 is the unstable, rolling development branch, which may eat
>>>> the hair of your head and may eat your family and children.
>>>> It's _you_ (The developers) who are testing and are supposed to find,
>>>> report and occasionally fix the bugs.
>>>
>>> Sebastian, maybe it makes sense to give gcc-4.7 a try. we have not yet
>>> branched off towards a 4.11 release, so Ralfs view seems reasonable to
>>> me.
>>
>> Thomas, I do not fully agree. The HEAD is the place for new development
>> and not suitable for production. Features and changes should be added
>> once they are stable, complete and tested. If you are working on changes
>> that can break others use your personal repo or a private repo until you
>> have stability. It is the developer's responsibility to track head and
>
> In general this makes sense. But due to the many architectures and
> targets supported by RTEMS and due to the limited automated test
> capabilities nobody is able to test a certain change in RTEMS code or
> tools for every target.

Yes there is a limit to the testing we can do and this will always be 
the case. How-ever I feel we can do better than we are if we were better 
organised.

>
> You can check, whether RTEMS can still be built for every supported
> targetafter a code patch a or toolset change, but that doesn't ensure,
> that the system is still functional.
>

We all tend to test a subset and not all the possible configuration 
combinations.

> IMHO, a possible development process would look like this:
>
> a) take HEAD of git-master as a starting point
> b) change RTEMS or toolset codecode or toolset
> c) test it to execute the test suite for all targets
> d) resync git with HEAD
> e) test it to execute the test suite for all targets
> f) apply patch back to git-master
>
> Unfortunately we have no standard procedure to execute steps c) or e).
> Most of us have access to some targets. We _might_ use the simulators as
> far as possible, but they only cover a subset of targets and architectures.
>

Agreed.

> So up to now everyone depends on "distributed testing", in parallel to
> the rtems-master HEAD development.
>
> It would be great to have a fast enough build system and an automated
> test bench that permanently gives feedback about the abilities to build
> and properly execute the test bench on all architectures and as many
> targets as possible. ;-)

I agree. The check out of fresh code to a completed build is too long to 
be practical for an automated build/regression type tool and that is 
without building the test suite. I feel RTEMS is gaining more 
configuration complexity and this is increasing the work load on 
maintainers and the places bugs creep in because we are not checking all 
cases. An example is the minor fix I made to the IMFS where no one for 
months has built with RTEMS_DEBUG enabled.

>
>> merge in changes while they work on new features. There is nothing
>> unusual in this, just common sense. I see no reason to treat the tools
>> any differently. The tool are pushed out with no staging, testing,
>> method of review and often no announcement. The patches used to build
>> the tools are jumbo and it is difficult to find the relationship to a
>> patch and documented fix in the upstream project. I have never seen any
>> test reports for the tools in the yum repo.
>
> We should cover this, maybe with a general test bench.
>

Yes, something that brings the testing under a common framework. This 
will help us organise the testing and I hope the reporting of the 
results. We need to take back up the the efforts of the development team 
with a trail of test results.

>> RTEMS is about the RTEMS code base and not a means to trial and test
>> tools. It is good engineering practice to vary only one thing at a time
>> and not to have 2 parts varying. Currently if you are adding new
>> features to the RTEMS code base you also have the adding uncertainty of
>> the state of the tools. As the recent bintutils powerpc bug has shown it
>> seems the developers attempting to work on RTEMS need to clean up and
>> fix tool issues in order to do the work on the RTEMS code.
>
> I see your point but have a slightly different view to it. Anyway we
> might need to adapt the way the toolsets are generated and maintained.
>
> During RTEMS code development, you may see patches on git that were
> developed in parallal to your own area of work, so at least when you
> sync back to git-master, you may find new patches/functionaliy.
>
> The toolset upgrades are quite similar: If you regard them like a patch
> that has come up, you see many similarities.

Yes they are and should tested to make sure there is no regression like 
I hope all patches are. If I am using a stable tool chain and it is 
updated to a new version, when I next update/merge I would expect to use 
those tools. I do not expect to find my ability to work on my new 
feature halted and I need to debug the tools because no one has built 
all effected archs and run the test suite.

>
> Things that may be different:
> - I am not sure how you can keep multiple toolsets on the same machine
> and switch between them. This would be of great help.

I have them. I build from source and use different prefixes with 
different paths to get the tool set mix I want. Being able to build from 
source in a controlled manner is an important need that has been lost to 
the project. The complication for me was/is the specification for the 
tools for RTEMS is hidden in a specific package management's 
specification file and no where else. My spec builder tools is my 
solution how-ever to be honest is it a hack to work around a more 
fundamental issue.

Chris

>
>>
>> I see us needing stable and experimental tool chains on head and release
>> branches. When a tool chain has suitable test reports from the gcc test
>> suite and the RTEMS test suite for the effected architectures the
>> project should be consulted about moving that specific tool set to stable.
>
> ACK.
>
> Thomas.