BSP Build Failures Appeal

[Chris Johns]

On 24/08/2014 7:59 pm, Pavel Pisa wrote:
> Hello Chris,
>
> On Sunday 24 of August 2014 05:33:45 Chris Johns wrote:
>> On 23/08/2014 1:57 am, Joel Sherrill wrote:
>>> The build failures I reported were with the latest RSB tools
>>> Please pitch in and let's resolve them.
>>
>> I have a regression build that includes building all BSPs using ...
>>
>> $ rm -rf build rsb-report-* log_* && ../source-builder/sb-set-builder
>> --prefix=$HOME/development/rtems/4.11 --log=log_all_rtems --with-rtems
>> --trace --regression 4.11/rtems-all
>>
>> ... running on sync.rtems.org as I am also seeing failures. This should
>> give me a list of error reports with the first failure on an architecture.
>>
>>> I left a similar build going for the weekend but using the
>>> head of gcc, newlib, and binutils. Hopefully the results
>>> are similar.
>>
>> Given the churn GSoC patches are creating I think we are still a while
>> away from a freeze before release branching 4.11.
>
> I have fault with latest RTEMS git on
>
>    tms570ls3137_hdk_intram
>    tms570ls3137_hdk_sdram
>    arm-lpc17xx_ea_ram
>    arm-lpc40xx_ea_ram
>

It is across most of the architectures including sparc without 
inspecting every error log.

> I expect that source of breakage is next commit
>
>    score: Add SMP support to the cache manager
>    http://git.rtems.org/rtems/commit/?id=ddbc3f8d83678313ca61d2936e6efd50b3e044b0
>

I agree.

> and the fact that CPU_INSTRUCTION_CACHE_ALIGNMENT does not get into defines
> for the most (or at least these without real cache) of ARM targets.

Daniel(s) ??

> May it be that some disable of SMP for CPUkit would help to these targets.
> But generally I am little afraid if cache management code does not
> cause overhead on systems without cache. In the theory there should
> be two builds of CPUkit for each multilib variant - one with SMP
> and another without if there is expected to build multiple BSPs
> against single CPUkit build.

Yes in theory this is correct. The intention of the cpukit was to 
support multilib building of RTEMS and a binary compatible layer all 
BSPs could use however linkages to parts of the source outside of the 
cpukit from within it has meant this has never been cleanly implemented 
and I suspect never will nor worth further efforts. The other major 
contributing factor is the multilibs for gcc is subset of the multilibs 
for RTEMS because the same instruction set can execute on a range of 
differing cores exploding the build matrix. This means building RTEMS 
for a BSP is practical.

> As I understand that is used for distribution
> but not common for source users who build for single BSP usually.
> But should be checked by someone who knows RTEMS better than me.

Multilib is not really used anywhere because of the complexities the 
configure options add. If you take ARM and it's increasing multilibs 
(gcc is taking a while to build on fast hardware these days) and then 
add the RTEMS number of specific variants and then multiple by the 
permutations of the configure options you have a massive build to 
support the distribution point of view. Then for a BSP you need to add 
on top of this BSPTOPS. So in theory each commit should run each of 
these variations for all BSPs to make sure nothing has broken however 
this is just not practical and that in my view means the way we handle 
configurations and variants is not sustainable and needs to change.

Patches need to be checked for this before being pushed and even then 
breakages like this happen from time to time.

Chris