Please add a preprocessor define to disable compilation of weak functions in the HAL

[riwe]

The STM32 HAL is good and simple. It's highly appreciated that I am not forced to use a certain build system. But there is one thing that drives me crazy: The STM32 HAL has lots of weakly defined symbols. That forces me to put any strong symbol overrides into objects linked with the executable. It is impossible to put the HAL and the strong symbol overrides into a or different static libraries. It's a nightmare. Consider projects where all hardware-related code is hidden in static libraries and the executable code is platform-independent.

A pragmatic solution could be to enclose all weak function definitions in the ST32 SDK inside ifdef guards to be able to switch those off. I will now copy the related HAL files out of the SDK and patch them on my own. That's not optimal because I will have to repeat that on every SDK update.

Please consider to fix this problem.

[riwe]

I do realize only now that I there is the option to register callbacks at run-time when enabling config defines like USE_HAL_ETH_REGISTER_CALLBACKS. That solves a big part of the problem. Nevertheless, the usage of weak default symbols remains questionable IMO.

[KnarfB]

Maybe these options help: c - How to make gcc link strong symbol in static library to overwrite weak symbol? - Stack Overflow

hth

KnarfB

[riwe]

Thanks, but no.

[Uwe Bonnes]

Please be verbose with what is wrong with the Stack overflow solution. Thanks

[riwe]

The mentioned workaround of using --whole-archive when linking has drawbacks

• the wrong (weak) symbol is still there. So the root cause is not solved, but just barely masked.
• it is a (highly) potential error source when integrating the library. The user has to take care of applying the flag correctly in the build system. There is no way to catch the error at build time unless you start double-checking symbol sizes. I have no control over the build system of my customers. Every hour that I spend with them debugging costs me money. I may be able to do partial linking before the libraries leave the house and kick the weak symbols out, but again, it would just be a workaround for an (IMO) questionable design decision.

To be honest, I was disappointed that @KnarfB did not show any notion of acknowledeging that ST's approach of predefining mandatory callbacks as weak symbols is in fact problematic. I am open to hear about the design considerations, but take my problem description from above as a customer feedback.

Anyway, I think I was able to solve the HAL part of the problem by setting the USE_HAL_XXX_REGISTER_CALLBACKS define to 1 in order to register the callbacks at run-time. The other problem with weak symbols in the generated startup_xxx.S file (interrupt handlers) was solved by modifying it and removing the weak symbol definitions. The file is generated after all, so no problem. I just don't want to touch the STM32 HAL code as it is updated frequently.

[Pavel A.]

>  I was disappointed that @KnarfB did not show any notion of acknowledeging that ST's approach of predefining mandatory callbacks as weak symbols is in fact problematic. 

Actually you are the first person bringing this issue as problematic, in several years. This suggests that majority of users manage to use the software as is. (and they may be annoyed by change of such scale unless justified).

Removing weak functions from your lib can be done with existing GNU utilities, something like following:

# unpack the lib:
ar x your_library.a
# For each object list weak symbols:
nm -a your_object.o | grep ' W ' | awk '{print $3}' > functions.txt
# then remove these functions
objcopy --strip-symbol=functions.txt your_object.o
# Then re-assembly the o files into .a
ar cr new_library.a *.o

> There is no way to catch the error at build time

Hmm. Perhaps this can be done with a "canary" , like this:

// canary_lib.c

// Add this in the .a library:
extern void link_is_broken(void); // isn't defined anywhere

void __attribute__((weak)) build_canary()
{
  link_is_broken();
}

// Add this in your main code
void build_canary() { /* nothing */ }

int main() { 
  .........  
   build_canary(); //use
  .......
}

If the weak function is selected, build will fail because of unresolved symbol.