Wait, so multiple definitions of a function are allowed?

[alexpaschoaletto]

TL:DR

Unless I'm missing something really obvious (apologies beforehand), Zephyr seems to be supporting multiple definitions of a function. The same function is defined three times on different subsystems, but no compilation error is thrown if all subsystems are included together. But shouldn't that be illegal?

Context

I am implementing a kernel feature which involves knowing when a thread has switched out of the CPU in order to execute accordingly. As far as I understand, this functionality is used within the kernel through the #define below:

file: zephyr/include/zephyr/tracing.h
/**
 * @brief Called before a thread has been selected to run
 */
#define sys_port_trace_k_thread_switched_out()

This define then become the same function in 3 different header files:

//file: zephyr/subsys/tracing/ctf/tracing_ctf.h
//file: zephyr/subsys/tracing/user/tracing_user.h
//file: zephyr/subsys/tracing/sysview/tracing_sysview.h

#define sys_port_trace_k_thread_switched_out() sys_trace_k_thread_switched_out()
void sys_trace_k_thread_switched_out(void);

Finally, for each corresponding .c file we have a different function declaration:

void sys_trace_k_thread_switched_out(void)        //file: zephyr/subsys/tracing/ctf/ctf_top.c
{
	struct k_thread *thread;
	ctf_bounded_string_t name = { "unknown" };
        ...
}

void sys_trace_k_thread_switched_out(void)        //file: zephyr/subsys/tracing/sysview/sysview.c
{
	SEGGER_SYSVIEW_OnTaskStopExec();
}

void sys_trace_k_thread_switched_out(void)        //file: zephyr/subsys/tracing/user/tracing_user.c
{
	sys_trace_thread_switched_out_user();
}

Which is all good if one decides to just enable one of these subsystems, as far as I know. Each one is protected by a kconfig option which is opt-in by default, so in order to use them we have to tweak our prj.conf. However, what if we accidentally do this?

CONFIG_TRACING=y
CONFIG_TRACING_USER=y
CONFIG_TRACING_CTF=y
CONFIG_SEGGER_SYSTEMVIEW=y

The answer is a successful compilation, instead of the classic "Multiple definitions of" error. BUT WHY?

I have checked a lot of files in search of an underlying settings override or something like that, but had no luck. All evidence I found so far suggest that indeed all subsystems coexist and are happily declaring their own versions of the function. Trying to apply the same pattern to my files resulted in the aforementioned error, however, so if anyone got a light on the subject I'd be very happy.
Many thanks in advance.

[yashi]

You can't. These are in a choice:

zephyr/subsys/tracing/Kconfig

Lines 26 to 68 in 6fc525c

	choice
	prompt "Tracing Format"
	default TRACING_NONE
	config TRACING_NONE
	bool "No tracing format selected"
	help
	None of the available tracing formats is selected.
	config PERCEPIO_TRACERECORDER
	bool "Percepio Tracealyzer support"
	select THREAD_NAME
	select INIT_STACKS
	select THREAD_MONITOR
	depends on ZEPHYR_PERCEPIO_MODULE
	config SEGGER_SYSTEMVIEW
	bool "Segger SystemView support"
	select CONSOLE
	select RTT_CONSOLE
	select USE_SEGGER_RTT
	select THREAD_MONITOR
	select SEGGER_RTT_CUSTOM_LOCKING
	config TRACING_CTF
	bool "Tracing via Common Trace Format support"
	select TRACING_CORE
	help
	Enable tracing to a Common Trace Format stream.
	config TRACING_TEST
	bool "Tracing for test usage"
	select TRACING_CORE
	help
	Enable tracing for testing kinds of format purpose. It must
	implement the tracing hooks defined in tracing_test.h
	config TRACING_USER
	bool "Tracing using user-defined functions"
	help
	Use user-defined functions for tracing task switching and irqs
	endchoice

[alexpaschoaletto]

Fair enough.
I looked up straight on the CMakeLists.txt (which only included the aforementioned files without any conditions other than their respective CONFIG_X options) and saw no warning of overrides being thrown in the compilation phase. The build system seems to be automatically overriding options of a same choice and leaving enabled only the last declared option.

IMHO, I think a little work has to be made here. From what I understand the SEGGER and CTF subsystems are not meant to be used by the kernel in any way; instead they are meant for the application developer to know what's going on. That is totally fine, but each subsystem implementation is effectively monopolizing the kernel tracing functions. A better approach would likely be to have a single function definition and hooks of each subsystem function, like this:

void sys_trace_k_thread_switched_out(void)
{
	#ifdef CONFIG_SEGGER_SYSTEMVIEW 
        segger_trace_k_thread_switched_out();
	#endif
	
	#ifdef CONFIG_TRACING_CTF
	ctf_trace_k_thread_switched_out();
	#endif
	
	#ifdef CONFIG_TRACING_USER
        user_trace_k_thread_switched_out();
	#endif
}

It's way more scalable than the current solution.