TMS570: more testing including combination with HalCoGen files for direct RTEMS startup and VFP

[Gedare Bloom]

On Sat, Nov 28, 2015 at 5:24 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> I have fight for while with GCC optimization to force it recognize
> that linker provided symbol is set to 0. The problem is that new
> C standard directly specifies that address of any legal global object
> declared in C cannot be equivalent to 0 (NULL). (optimizes checks
> for global variabless adress to be zero out). When object/symbol
> is placed at address 0 then behavior is undeffined. I have been avare
> of this standard change but hoped that RTEMS
>
>   tms570/rtem~hared/include/linker-symbols.h
>
> combined with cast to (uintptr_t) whould be enough.
> It is not.
>
>   #define LINKER_SYMBOL(sym) extern char sym [];
>
> Symbol address is delivered as address of start of array
> and GCC utilizes full freedom given by standard.
> So comparison of any symbol provided by this header
> to zero/non zero can be optimized out.
>
> I have come with next workaround to ensure that GCC
> cannot predict that compared value is equivalent
> to address of static/global object.
>
> -  if ( (uintptr_t)bsp_start_vector_table_begin != 0 ) {
> +  asm volatile ("\n": "=r" (need_remap_int): "r" (need_remap_ptr));
> +  if ( need_remap_int != 0 ) {
>
> Code generated with this change is correct and really
> switches POM off for application located at start
> of memory map. I prepare patch for this and run more tests.
>
> Observed problem can affect much more BSPs and places
> in RTEMS. Usage of all linker symbols in RTEMS should
> be checked.
>
Can we (do we want to) suppress the particular optimization?

If the suggested approach is deemed "best", then we should create some
macros to facilitate using it.

I seem to recall similar problems related to vector addresses in some
other BSP but I can't find any email about it.

Gedare