[U-Boot] [PATCH] lib: disable hashtable and display options code in SPL
We do not need hashtable code in SPL when building without environment support. Also display options code is not used in current SPL configuration and can be disabled.
Signed-off-by: Anatolij Gustschin agust@denx.de --- lib/Makefile | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/Makefile b/lib/Makefile index 2eef1eb..1ffa455 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_TPM) += tpm.o obj-$(CONFIG_RBTREE) += rbtree.o obj-$(CONFIG_BITREVERSE) += bitrev.o obj-y += list_sort.o +obj-y += hashtable.o endif
obj-$(CONFIG_RSA) += rsa/ @@ -61,10 +62,14 @@ obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o obj-$(CONFIG_SPL_NET_SUPPORT) += net_utils.o endif obj-$(CONFIG_ADDR_MAP) += addr_map.o -obj-y += hashtable.o obj-y += errno.o +ifdef CONFIG_SPL_BUILD +obj-$(CONFIG_SPL_ENV_SUPPORT) += hashtable.o +endif +ifndef CONFIG_SPL_BUILD obj-y += display_options.o CFLAGS_display_options.o := $(if $(BUILD_TAG),-DBUILD_TAG='"$(BUILD_TAG)"') +endif obj-$(CONFIG_BCH) += bch.o obj-y += crc32.o obj-y += ctype.o
On Mon, Aug 28, 2017 at 05:53:08PM +0200, Anatolij Gustschin wrote:
We do not need hashtable code in SPL when building without environment support. Also display options code is not used in current SPL configuration and can be disabled.
Signed-off-by: Anatolij Gustschin agust@denx.de
lib/Makefile | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
This and https://patchwork.ozlabs.org/patch/806646/ don't give you what you want I think. First, take a look at https://gist.github.com/trini/fb85b11f6337ea9d5d65736762c678ac as these patches break a number of platforms (there are SPL cases where we do need these). And with gcc-6.x and later (which is being required with v2018.01, which is really soon now), we finally have strings discarded along with functions, so there's no size savings being seen in almost every case (it would be interesting to see what the savings is in Cyprus* and those few arm cases where we do save a tiny bit of text).
In sum, I don't think we want either of these patches, even with the link errors fixed unless you can show some size savings with gcc-6 or later. But those cases in the above gist were size is reduced could hint at places to look for a different set of changes to make here, perhaps. Thanks!
participants (2)
-
Anatolij Gustschin -
Tom Rini