NUM_KERNEL_OBJECT_FILES is too small

[andrewboie]

I found this when trying to build frdm_k64f/tests/drivers/build_all/test_build_sensors_a_m

In file included from /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/include/arch/arm/cortex_m/scripts/linker.ld:21:0,
                 from /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/arch/arm/soc/nxp_kinetis/k6x/linker.ld:31:
/home/buildslave/src/github.com/zephyrproject-rtos/zephyr/include/linker/linker-defs.h:115:2: error: #error "Max supported kernel objects is 32."
 #error "Max supported kernel objects is 32."
  ^~~~~

32 is unreasonably small limit of the number of .o files for a real-world application.

[andrewboie]

Apparently this is a limitation of UTIL_LISTIFY and we really need to just get rid of this.

#ifndef NUM_KERNEL_OBJECT_FILES
#error "Expected NUM_KERNEL_OBJECT_FILES to be defined"
#elif NUM_KERNEL_OBJECT_FILES > 32
#error "Max supported kernel objects is 32."
/* TODO: Using the preprocessor to do this was a mistake. Rewrite to
   scale better. e.g. by aggregating the kernel objects into two
   archives like KBuild did.*/
#endif

[lpereira]

I would even rename UTIL_LISTIFY to _UTIL_LISTIFY to discourage it being used by people and make it easier to get rid of it in the next version.

[SebastianBoe]

I would even rename UTIL_LISTIFY to _UTIL_LISTIFY to discourage it being used by people and make it easier to get rid of it in the next version.

I wouldn't go that far ...

It is useful to generate sequences of code that are relatively short.

e.g. it is the cleanest possible solution (that I know of) to solve problems like the below.

#define TIMER_IRQHANDLER_GENERATOR(j, _)                                                            \
    void TIMER##j##_IRQHandler(void)                                                                \
    {                                                                                              \
        timer_i_irqhandler(j);                                                                      \
    }

#ifdef TIMER_COUNT
STD_SHARED_LIB_LISTIFY(TIMER_COUNT, TIMER_IRQHANDLER_GENERATOR)
#endif

It was just inappropriately used here.

[andrewboie]

IMO UTIL_LISTIFY needs to die and we should just generate the code with a post-build step. It just doesn't scale. I am not sure if #7632 (the successor to CONFIG_APPLICATION_MEMORY) needs it.