Inline decarations need replacing by static declarations

[TerryE]

Expected behavior

The application should compile clean if the optimization level is set of O0

Actual behaviour

The link app/lua fails on undefined vfs references in luaxlib.c and loadlib.c

Test code

Replace references to O2 by O0 in the root Makefile, rm -R app/lua/.output and remake.

NodeMCU version

current dev

Root cause

See Stackoverflow: gcc fails to inline functions without -O2. The app/platform/vfs.h header uses the inline, but in In C99, this means that function's definition is provided only for inlining and inlining is not carried out at O0 so the function isnot compiled in. These functions should be declared static instead of inline and the compile will inline them anyway at O2.

One for @devsuarus

PS I note that app/coap/coap.c, app/coap/coap.c, and app/fatfs/myfatfs.c have the same issue.

[devsaurus]

Right, I can reproduce this with DEBUG=1 make. Will have a look.

[TerryE]

@devsaurus Hi Arnim, AFAIK it's a foible of C89 vs C99. Up to C89 inline was a directive meaning a static function that may generate an inline expansion with the appropriate optimisation level. In C99 inline function template only generate code if the optimisation level allows it. The main issues that triggers this is that the xtensa-lx106-elf-gdb remote debugging is such a PITA to use with O2 that its just easier to recompile the modules that you are working on as O0 (or in my case app/lua) exposing this barf. 😄

The current gcc generators just generate gobsmackingly good code in general and will often inline any non-forward referenced function if this results in a shorter / faster code sequence. So IMO, we should just substitute static for inline declarations in the few places that we use them.

[TerryE]

Oops sorry; closed in error. Finger trouble and clicked the wrong button.

[devsaurus]

The compiler's obviously smart enough (even with the our -Os) to figure out that the vfs wrappers don't have any flesh and declaring them as inline wasn't needed after all 😄

[TerryE]

-Os is a bad choice for us. About the only material difference between it and -O2 is that Flash string constants are packed and not word aligned so the unaligned exception handler counts go through the roof. I always compile with -O2.

[devsaurus]

-Os is a bad choice for us

Should we make -O2 the default then? What would be the drawback of this - increased image size?

[TerryE]

@devsaurus, there is a increase in the Flash image size, a few % if I recall, but the typical count of unaligned exceptions goes down by over 5x so this is well worth doing. We've already touched on this in #1590 and #2146 (which is where we should address this).

[TerryE]

This patch has already been picked up be @devsaurus so there's no point in keeping this issue open.