Misleading code size reporting when -ffunction-sections option is used
MarkHillHuawei opened this issue · 7 comments
I have noticed that the code size reporting by benchmark_size.py is a bit misleading when the -ffunction-sections compilation option is used. This is because the text section is split into multiple sections with '.text' suffixed by the function name, for example .text.fred. However the script only looks for precise matches when determining which sections to count. I think the script needs to be modified to scan all section names and include any that match the specified prefix (in this example .text).
Also, the python script doesn't take into consideration all CODE sections. For example, there may be code sections which are not called .text and they are not considered in the final numbers.
You can easily see this when comparing the size figures obtained with the python script versus the numbers reported by the gnu size utility.
Do you observe this behavior in the final object file of each benchmark after the link step?
Because I think the default linker script tells the linker to collect all the .text.* sections into a single .text.
If you are not using the default linker script, it is also possible to act there.
Hi all,
thank you for all the input.
That's right, I've seen too that there's a difference between the size calculated by the script and the numbers reported by the size utility. That is because of the rodata section, that the readlelf and the size utilities seem to add in the text size. I've also seen that with the riscv gcc the size adds also the size of the bss to the text section.
I'd rather keep the benchmark_size.py script as flexible as it is to select the .text, .rodata, .data, .bss setion(s) and allow to compare different architectures (that might have different grouping of the same sections in their default linker scripts) on equal selections of the sections.
It could be worth considering to add an extra option to the size benchmark (as the default option or an extra one) to get a more 'collective' number for the size, that might include both the text sections and the rodata sections for instance, like the size utility does. That needs to be considered carefully though considering the differences between the architectures and the freedom to use custom linker scripts.
That is my opinion anyway. Any different angle that I'm missing is very much welcome.
I changed the script in order to select not only the .text section, but also all the derivative ones (.text*). The same applies to the other sections.
I'll make a pull request soon.
Thank you again,
Paolo
My fix of the script is on master.
It is a temporary fix that should do well enough for embench 0.5.
I would close this issue while keeping note of your advice for improving this feature for future versions.
Thank you all,
Paolo
Marking as closed