#5 inline trace giving undefined reference for other than -Og

[diabolo38]

eclipse kepler 8.3 sr2
gcc Tools ARM Embedded 4.8 2013q4
GNU ARM Eclipse Plug-in. Version: 0.5.5.201310221100

Starting from "free stranding" cortex m4 with initial trace selected
remove "TRACE" from project symbols
go into project properties build setting
Set optimization to O0 (same for over o1 o2 ...)
build
We get undefined reference to "empty body" in-lined trace function

/../src/main.c:47: undefined reference to trace_puts' ../src/main.c:51: undefined reference totrace_printf'
....

i believe gcc doesn't always inline function even if declare/implemented "inline" in an header.
I've been told and i'm always using "static" for such header function but can't remnember exactly why. It must somehow to prevent multiple definition when the "inline" function traces appear in several .o file (not the case with these gcc version)

So a possible correction it to add static qualifier in header file

static inline int
trace_puts(const char *s attribute((unused)))
{
return 0;
}

it's one more arguments in favor of macro ;)
attached modified trace.h with static

[diabolo38]

wrong version (copied from older eclipse open)

GNU ARM C/C++ Generic Cortex-M Project Template 1.1.1.201403281421

[Liviu Ionescu (ilg)]

i believe gcc doesn't always inline function even if declare/implemented "inline" in an header.

that's correct, gcc makes this decision based on several other options, active or not on various optimisation levels.

go force it, attribute((always_inline)) must be used.

I've been told and i'm always using "static" for such header function but can't remnember exactly why.

generally it is true, but with always_inline it makes no difference.

---

I just published a new version, the inlines should work on any optimisation level, i.e. should not generate any code at all.

please test again the generic template. the F4, F1, F0 templates are also ready for testing, F3 and F2 are work in progress.

[Liviu Ionescu (ilg)]

it's one more arguments in favor of macro ;)

as any C++ programmer can tell, except for passing configuration values and conditional compiling, I prefer to avoid macros as much as possible.

in case you did not notice, I'm slowly transitioning these templates to C++ (most source files are now shared from my other project µOS++, which is a C++ project).