Hi Tom,
On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote:
On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which would point out the culprit configs. This is hardly achievable, but looks good on the paper!
CONFIG FILE SIZE
CONFIG_FEATURE_A 10.7Mi 37.1% CONFIG_FEATURE_B 5.39Mi 18.6% CONFIG_FEATURE_C 4.48Mi 15.5% CONFIG_FEATURE_D 1.86Mi 6.4% CONFIG_FEATURE_E 1.67Mi 5.8% CONFIG_FEATURE_F 1.61Mi 5.6% CONFIG_FEATURE_G 856Ki 2.9% CONFIG_FEATURE_H 470Ki 1.6% .... TOTAL 28.9Mi 100.0%
This is relatively easy to do today, with buildman and a local commit to enable/disable CONFIG_FEATURE_A.
Being a valid choice doesn't make it necessarily appealing, especially with 512 [1] configurations enabled in sandbox and knowing that U-Boot is not really randconfig-grade [2] (the latter is being improved).
What I was alluding to is embedding the Kconfig symbol names into the ELF objects, such that utilities like 'nm' (currently producing a nice output of symbol sizes [3]) can also be made capable to report the exact Kconfig symbols contributing to the size of the objects passed as input. That would be, in my opinion, mind-blowingly useful.
[1] grep "CONFIG.*=" .config | wc -l 512
[2] https://patchwork.ozlabs.org/patch/1074420/
[3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o 0000000000000421 0000000000000024 T clk_free 0000000000000961 0000000000000027 T clk_disable 0000000000000888 0000000000000027 T clk_enable 0000000000000000 0000000000000027 T clk_request 0000000000000503 0000000000000027 T clk_set_parent 0000000000000445 0000000000000029 T clk_get_rate 0000000000000474 0000000000000029 T clk_set_rate ...