On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote: > 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% > > > > > > [1] https://github.com/google/bloaty > > > > 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
Right. More numbers, and more easily readable is good. But to be clear, since we use -ffunction-sections / -fdata-sections (and the kernel doesn't normally), we get can get a lot more detail than I might have implied. It's not just that you'll see that U-Boot shrank X bytes with CONFIG_FEATURE_A disabled, it's that you'll see which functions shrank by how much. What we don't have is the link between "CONFIG_OPTION_X" and "is part of functions A/B/C". But we have a lot of information like you would get out of nm already in u-boot*.map which also includes "and we discarded these functions". -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot