EMB2.0: Automatic stdlib size overhead adjustment

[I-mikan-I]

We try to subtract the size overhead for libraries, startup files, crt when calculating the size of benchmarks. Currently this is done as follows:

• Each benchmark is linked against "dummy" libraries that are empty
• The size of the executable elf is calculated by summing up certain sections

Issues with the current approach

• Crt/startup files may still be linked to the final executable
• requires a user to specify dummy files for any user libraries

New approach (planned for embench-iot 2.0)

• Compile a "dummy benchmark", which is empty and gets linked with support files/libraries
• Compute the size of said dummy and subtract it from each benchmark when computing the size.

[I-mikan-I]

addressed in ace099eefb4fcc

[I-mikan-I]

There are some issues i see with the new approach:

• The linker may eliminate unused library symbols because they aren't used by the dummy benchmark, but would be used in the actual benchmarks
  • this results in negative sizes for some sections
  • one fix that i used in the commit is to compile with -rdynamic/-Wl,--export-dynamic, which exports all symbols
• This cannot account for separate libraries used in each benchmark, such as -lm

Perhaps it would be a better idea to compile each benchmark as a shared library with -nostartupfiles -nostdlib -c?

[jeremybennett]

I'm not sure that shared libraries help if you are going to compile down for a small embedded device.

One option is to use attributes to force particular functions and symbols to be retained. Would adding __attribute__ ((noinline)) __attribute__ ((externally_visible)) to the declaration of the relevant functions do the trick?

[I-mikan-I]

I'm not sure that shared libraries help if you are going to compile down for a small embedded device.

It wouldn't be possible to run them as dylibs, i just thought if you compile them as such, you remove any libraries and startup files from the elf/macho and can get an accurate size measurement for the code size. If we want to run the same file that we measured the size of then this isn't viable.

One option is to use attributes to force particular functions and symbols to be retained. Would adding __attribute__ ((noinline)) __attribute__ ((externally_visible)) to the declaration of the relevant functions do the trick?

Thanks, I'll try this attribute. This should improve --export-dynamic by also preventing inlining.

[I-mikan-I]

I compared the results of either using __attribute__ ((noinline)) __attribute__ ((externally_visible)), or using -Wl,--export-all.

The --export-all variant seems to be more accurate: for tarfind it reports a size of 265 bytes, the actual size of the benchmark_body code being 260 bytes.

[simonpcook]

I thought it was previously discussed that embench was moving away from library subtraction in part because of issues like the ones you’ve raised, did this now change?