[U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Changes in v2: - Rephrase comments for clarification - Fix a typo
Masahiro Yamada (2): kbuild: add stringify helper to quote a string passed to C files kbuild: redefine __FILE__ as relative path from $(srctree) if possible
Michal Marek (1): kbuild: Get rid of KBUILD_STR
Makefile | 9 +++++++++ scripts/Kbuild.include | 4 ++++ scripts/Makefile.lib | 8 ++++---- 3 files changed, 17 insertions(+), 4 deletions(-)
From: Michal Marek mmarek@suse.com
The compiler can accept -DKBUILD_MODNAME="foo", it's just a matter of quoting. That way, we reduce the gcc command line a bit.
Signed-off-by: Michal Marek mmarek@suse.com Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
[ Linux commit: b42841b7bb6286da56b4fa79835c27166b7e228b ] ---
Changes in v2: None
scripts/Makefile.lib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 0d5c529..8934b2f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -99,10 +99,10 @@ obj-dirs := $(addprefix $(obj)/,$(obj-dirs)) # Note: Files that end up in two or more modules are compiled without the # KBUILD_MODNAME definition. The reason is that any made-up name would # differ in different configs. -name-fix = $(subst $(comma),_,$(subst -,_,$1)) -basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call name-fix,$(basetarget)))" +name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst -,_,$1))$(quote)$(squote) +basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) modname_flags = $(if $(filter 1,$(words $(modname))),\ - -D"KBUILD_MODNAME=KBUILD_STR($(call name-fix,$(modname)))") + -DKBUILD_MODNAME=$(call name-fix,$(modname)))
orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \ $(ccflags-y) $(CFLAGS_$(basetarget).o) @@ -154,7 +154,7 @@ endif # Modified for U-Boot: LINUXINCLUDE -> UBOOTINCLUDE c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ $(__c_flags) $(modkern_cflags) \ - -D"KBUILD_STR(s)=#s" $(basename_flags) $(modname_flags) + $(basename_flags) $(modname_flags)
a_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ $(__a_flags) $(modkern_aflags)
I want to reuse $(squote)$(quote)...$(quote)$(squote) in the next commit. Move it to a helper.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com ---
Changes in v2: None
scripts/Kbuild.include | 4 ++++ scripts/Makefile.lib | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 2c7918a..48a641c 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -30,6 +30,10 @@ baseprereq = $(basename $(notdir $<)) escsq = $(subst $(squote),'$(squote)',$1)
### +# Quote a string to pass it to C files. foo => '"foo"' +stringify = $(squote)$(quote)$1$(quote)$(squote) + +### # Easy method for doing a status message kecho := : quiet_kecho := echo diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 8934b2f..bd0977e 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -99,7 +99,7 @@ obj-dirs := $(addprefix $(obj)/,$(obj-dirs)) # Note: Files that end up in two or more modules are compiled without the # KBUILD_MODNAME definition. The reason is that any made-up name would # differ in different configs. -name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst -,_,$1))$(quote)$(squote) +name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1))) basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) modname_flags = $(if $(filter 1,$(words $(modname))),\ -DKBUILD_MODNAME=$(call name-fix,$(modname)))
Since Kbuild runs in the objtree, __FILE__ can be a very long path depending of $(srctree).
If objtree is a child of srctree, the situation is a bit better. ($(srctree) is "..")
For other cases of out-of-tree build, filenames in WARN_ON() etc. are still an absolute path. It also means the U-Boot image depends on where it was built.
Here, the idea is to redefine __FILE__ as the relative path from $(srctree), but doing so causes a compiler warning: warning: "__FILE__" redefined [-Wbuiltin-macro-redefined]
The option -Wno-builtin-macro-redefined can suppress it, but it is only recognized by GCC 4.4 or newer. Redefine __FILE__ only when possible.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com ---
Changes in v2: - Rephrase comments for clarification - Fix a typo
Makefile | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile index 888486b..1ff312a 100644 --- a/Makefile +++ b/Makefile @@ -1334,6 +1334,15 @@ prepare0: archprepare FORCE # All the preparing.. prepare: prepare0
+# If possible, redefine __FILE__ as relative path from $(srctree). +# $$ is needed to evaluate the variables in sub-directories. +ifeq ($(call cc-option-yn,-Wno-builtin-macro-redefined),y) +KBUILD_CFLAGS += -Wno-builtin-macro-redefined \ + -D__FILE__=$$(call stringify,$$(src)/$$(notdir $$<)) +endif +# CAUTION: Do not add any reference to KBUILD_CFLAGS below this line. +# $(call cc-option,...) etc. may return wrong result. + # Generate some files # ---------------------------------------------------------------------------
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
On Fri, Oct 13, 2017 at 09:21:19PM +0900, Masahiro Yamada wrote:
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
FWIW, a world build is: https://gist.github.com/trini/ad0f55b9f46997fd11801aac48bf0c10
I wonder why we see size increase in a few cases? In both cases, the obj directory is /tmp/something/01_of_.. (or 04_of_..)/current/..
2017-10-13 22:53 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 09:21:19PM +0900, Masahiro Yamada wrote:
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
FWIW, a world build is: https://gist.github.com/trini/ad0f55b9f46997fd11801aac48bf0c10
I wonder why we see size increase in a few cases? In both cases, the obj directory is /tmp/something/01_of_.. (or 04_of_..)/current/..
Hmm, this patch seems buggy.
At least, it is not working at all for SPL.
I will take a look.
2017-10-13 22:53 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 09:21:19PM +0900, Masahiro Yamada wrote:
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
FWIW, a world build is: https://gist.github.com/trini/ad0f55b9f46997fd11801aac48bf0c10
I wonder why we see size increase in a few cases? In both cases, the obj directory is /tmp/something/01_of_.. (or 04_of_..)/current/..
Figured out.
This patch changes the string in some places where BUG() etc. is used in functions included from another .c file.
For example,
drivers/usb/gadget/composite.c is included from drivers/usb/gadget/g_dnl.c
The BUG_ON() in composite_unbind(), previously printed drivers/usb/gadget/composite.c, but will print drivers/usb/gadget/g_dnl.c with this patch.
This is the cause of slight increase/decrease.
Then, I do not have a solution...
On Sat, Oct 14, 2017 at 03:35:23AM +0900, Masahiro Yamada wrote:
2017-10-13 22:53 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 09:21:19PM +0900, Masahiro Yamada wrote:
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
FWIW, a world build is: https://gist.github.com/trini/ad0f55b9f46997fd11801aac48bf0c10
I wonder why we see size increase in a few cases? In both cases, the obj directory is /tmp/something/01_of_.. (or 04_of_..)/current/..
Figured out.
This patch changes the string in some places where BUG() etc. is used in functions included from another .c file.
For example,
drivers/usb/gadget/composite.c is included from drivers/usb/gadget/g_dnl.c
The BUG_ON() in composite_unbind(), previously printed drivers/usb/gadget/composite.c, but will print drivers/usb/gadget/g_dnl.c with this patch.
This is the cause of slight increase/decrease.
Then, I do not have a solution...
Ah yes, this was the potential complication with going down this path... Thanks!
2017-10-14 6:39 GMT+09:00 Tom Rini trini@konsulko.com:
On Sat, Oct 14, 2017 at 03:35:23AM +0900, Masahiro Yamada wrote:
2017-10-13 22:53 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 09:21:19PM +0900, Masahiro Yamada wrote:
2017-10-13 21:11 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Oct 13, 2017 at 06:51:42PM +0900, Masahiro Yamada wrote:
We discussed the __FILE__ problem when U-Boot is built out of tree. https://www.mail-archive.com/u-boot@lists.denx.de/msg242852.html
The deeper your build directory is located, the larger your U-Boot image becomes. If your platform has memory footprint limit, this is a problem.
Recently, I submitted the following patches to Kbuild ML. (no RFC, this time) https://patchwork.kernel.org/patch/10001419/ https://patchwork.kernel.org/patch/10001409/
I consider them for Linux 4.15 unless there is a strong objection or a problem report.
This series is a port for U-Boot.
If Tom wants to pick this up earlier, it is OK. If not in hurry, you can wait for the activity in Linux. Either will do.
Yay. I plan to pick these up after v2017.11 has been released, so no need to re-spin this if it stops applying cleanly until we're closer to release. Thanks!
Good.
According to this: http://phb-crystal-ball.org/
The MW for v4.15 will open 2017-11-12.
So, the next MW for U-Boot and Linux will be almost lined up.
You will be able to apply it more confidently if Linus pulls the Linux counterpart.
Until then, I will test it in linux-next.
FWIW, a world build is: https://gist.github.com/trini/ad0f55b9f46997fd11801aac48bf0c10
I wonder why we see size increase in a few cases? In both cases, the obj directory is /tmp/something/01_of_.. (or 04_of_..)/current/..
Figured out.
This patch changes the string in some places where BUG() etc. is used in functions included from another .c file.
For example,
drivers/usb/gadget/composite.c is included from drivers/usb/gadget/g_dnl.c
The BUG_ON() in composite_unbind(), previously printed drivers/usb/gadget/composite.c, but will print drivers/usb/gadget/g_dnl.c with this patch.
This is the cause of slight increase/decrease.
Then, I do not have a solution...
Ah yes, this was the potential complication with going down this path... Thanks!
I marked them Rejected except 1/3.
1/3 is a stable commit imported from Linux.
participants (2)
-
Masahiro Yamada -
Tom Rini