Matteo Concas created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5258
## Summary When building the GR740 BSP with `RTEMS_MULTIPROCESSING` set to `true` , the build will fail. ## Steps to reproduce The INI file contents are: ``` [DEFAULT] RTEMS_POSIX_API = True [sparc/gr740_mp] INHERIT=gr740 RTEMS_MULTIPROCESSING=True ``` I configure the Waf system with: `./waf configure --prefix=$RTEMS_PREFIX --rtems-config=gr740.ini` And then `./waf` to build the BSP. I get the following output: ``` Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build' Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build' 'build' finished successfully (0.081s) Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp' [ 167/1641] Compiling bsps/sparc/leon3/clock/ckinit.c In file included from ../../../bsps/sparc/leon3/clock/ckinit.c:46: ../../../bsps/sparc/leon3/clock/ckinit.c: In function 'leon3_clock_initialize': ../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'? 221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index ) | ^~~~~~~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX' 181 | timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX]; | ^~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: note: each undeclared identifier is reported only once for each function it appears in 221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index ) | ^~~~~~~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX' 181 | timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX]; | ^~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h: In function '_Clock_Initialize': ../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'? 221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index ) | ^~~~~~~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/ckinit.c:137:49: note: in expansion of macro 'LEON3_CLOCK_INDEX' 137 | #define Adjust_clkirq_for_node() do { clkirq += LEON3_CLOCK_INDEX; } while(0) | ^~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/ckinit.c:145:7: note: in expansion of macro 'Adjust_clkirq_for_node' 145 | Adjust_clkirq_for_node(); \ | ^~~~~~~~~~~~~~~~~~~~~~ ../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h:249:3: note: in expansion of macro 'Clock_driver_support_find_timer' 249 | Clock_driver_support_find_timer(); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp' Build failed -> task in '/bsps/sparc/leon3/obj' failed with exit status 1 (run with -v to display more information) ``` ## Expected behaviour Build should complete successfully. ## Possible fix >From my own investigation this comes from >`bsps/sparc/leon3/include/bsp/leon3.h` . `leon3_timer_core_index` is only >declared if `LEON3_GPTIMER_BASE` is not defined but later in the file the >`LEON3_CLOCK_INDEX` macro is defined in the following way: ```c /** * @brief This constant defines the index of the GPTIMER timer used by the * clock driver. */ #if defined(RTEMS_MULTIPROCESSING) #define LEON3_CLOCK_INDEX \ ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index ) #else #define LEON3_CLOCK_INDEX 0 #endif ``` So when `RTEMS_MULTIPROCESSING` is used the `LEON3_CLOCK_INDEX` will expand to use the `leon3_timer_core_index` variable which won't be declared as the GPTIMER base is defined for the GR740 BSP. I don't fully understand why the `LEON3_CLOCK_INDEX` macro is defined this way but changing it's define conditional to: ```c #if defined(RTEMS_MULTIPROCESSING) && !defined(LEON3_GPTIMER_BASE) ``` Will make the BSP build successfully, I haven't had the time to test this fix, it might break something else at runtime. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5258 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs