cancel
Showing results for 
Search instead for 
Did you mean: 

Changing main.c to cpp adds floating point routines to the binary & increases size - why?

SKled.1
Senior II

I have a STM32CubeIDE project for a stm32f091, using LL drivers for everything.

So I initially used the Cube-generated project structure with its main.c file.

In an attempt to decrease the binary size (irony alert!) I converted the large GPIO init routine with lots of repated GPIO initialization code to one what uses a compact const array of struct storage for the GPIO / init info, and a small code block in a loop to do the config.

To do that more conveniently I used some own helper library header with compile-time computation and "packing" stuff heavily reliant on the "constexpr" keyword.

So I changed main.c into main.cpp. i.e. having it compile with C++.

(the vast majority of the project was already C++, btw.)

I did not change anything in the project but that (I just looked at the git diff), added no computations that use float or anything.

But now instead of smaller, my binary is ~ 10KB bigger, and 7KB of that are from items in the .text section which were not present before:

  • __aeabi_dsub
  • __aeabi_dadd
  • __aeabi_ddiv
  • __aeabi_dmul
  • __ieee754_log

I can't quite explain why these things are in there now.

I tried to inspect the .map file to maybe see what's using it, but anything listed that mentions any of those above are seemingly library things, I can't see any of my stuff using it.

What's going on? Can I get rid of that?

1 ACCEPTED SOLUTION

Accepted Solutions
SKled.1
Senior II

Hah!

Somehow this slipped by me.

One of the mentioned own library routines was somehow using __builtin_log2. Albeit in a supposedly constexpr context which was expected to be executed at compile-time only, but apparently not.

Anway, after replacing that with my own constexpr routine to do a log2 in integer, the binary did not include any of that stuff anymore.

View solution in original post

3 REPLIES 3
SKled.1
Senior II

Hah!

Somehow this slipped by me.

One of the mentioned own library routines was somehow using __builtin_log2. Albeit in a supposedly constexpr context which was expected to be executed at compile-time only, but apparently not.

Anway, after replacing that with my own constexpr routine to do a log2 in integer, the binary did not include any of that stuff anymore.

Ozone
Lead II

IMHO a good method to tackle such an issue is the map file.

Just trace back which functions call routines like the ones mentioned.

Even a misspelled numeric preprocessor constant can be the cause.

SKled.1
Senior II

I wasn't seeing much in the map file. (I did add the cross references flag) But then, I probably have too superficial an idea of what's in there.

Are there options to completely "forbid" to use any (soft) floating point routines, such that it will generate an error and tell me where the "forbidden code" is?