On Fri, Mar 20, 2020 at 6:21 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > >> -O --> works > >> -O2 --> works > >> -O3 --> works > >> -O0 --> fails > >> -Os --> works > > Because it builds when optimization is on, and because the error you > > posted in your original post is a linker error, that leads me to the > > following hypothesis: > > > > I think that with optimization turned on, there is some automatic dead > > code removal happening. That is, functions that are unused are removed > > from the link. ... > > I don't think so. static inline functions never generate code if they > are not referenced and included inline. >
No, inline is just an optimization hint to compiler, compiler can ignore it as needed(e.g. in O0 case). Nathan's analysis is right, the problem is that: 1.Compiler doesn't remove the unused mpu_configure_region from the final image in O0 case 2.mpu_configure_region call mpu_allocregion 3.But stm32h7 compile and link up_mpu.c(mpu_allocregion implmented here) only in PROTECTED mode We can't complain item 1 is the compiler's fault because the standard never request that compiler must remove the unused function even it's static or inline. The problem is that our code depend on the undefined compiler behaviour(removing the unused function). The fix could be: 1.Include mpu.h conditionally in arch/arm/src/stm32h7/stm32_allocateheap.c: #ifdef CONFIG_ARM_MPU # include "mpu.h" #endif 2.Always compile and link up_mpu.c in arch/arm/src/stm32h7/Make.defs > More likely is the fact that inlining is disabled at -O0 and now the > functions really are implemented as static functions and generate static > functions. Now you really do have unreferenced static functions. Try > removing the static storage class from the inline prototypes. > > > > > Those functions, the unused ones removed from the link, > > are calling other functions that are not found because preprocessor > > conditional logic (based on Kconfig settings) is excluding them from > > ever being compiled. But everything builds successfully because the > > linker doesn't care about resolving dependencies of functions that are > > never called. > > > > But... With optimization turned off, the linker is trying to link > > everything, including the unused functions, and then it realizes that > > it can't find the nonexistent functions referenced by the unused > > functions. > > > > How's that for long-winded? > > > > Again, this is a *hypothesis* based on everything I read in this thread so > > far. > > > > You might want to check if your default options include > > -ffunction-sections, -fdata-sections, and/or -Wl,–gc-sections. If so, > > that would be in favor of the above. > > > > Cheers, > > Nathan > >
