On Sat, Nov 28, 2015 at 5:24 AM, Pavel Pisa <[email protected]> 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 _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
