* [U-Boot] [PATCH v2 1/3] kbuild: Get rid of KBUILD_STR
2017-10-13 9:51 [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Masahiro Yamada
@ 2017-10-13 9:51 ` Masahiro Yamada
2017-10-13 9:51 ` [U-Boot] [PATCH v2 2/3] kbuild: add stringify helper to quote a string passed to C files Masahiro Yamada
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 9:51 UTC (permalink / raw)
To: u-boot
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)
--
2.7.4
^ permalink raw reply related [flat|nested] 11+ messages in thread* [U-Boot] [PATCH v2 2/3] kbuild: add stringify helper to quote a string passed to C files
2017-10-13 9:51 [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Masahiro Yamada
2017-10-13 9:51 ` [U-Boot] [PATCH v2 1/3] kbuild: Get rid of KBUILD_STR Masahiro Yamada
@ 2017-10-13 9:51 ` Masahiro Yamada
2017-10-13 9:51 ` [U-Boot] [PATCH v2 3/3] kbuild: redefine __FILE__ as relative path from $(srctree) if possible Masahiro Yamada
2017-10-13 12:11 ` [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Tom Rini
3 siblings, 0 replies; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 9:51 UTC (permalink / raw)
To: u-boot
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)))
--
2.7.4
^ permalink raw reply related [flat|nested] 11+ messages in thread* [U-Boot] [PATCH v2 3/3] kbuild: redefine __FILE__ as relative path from $(srctree) if possible
2017-10-13 9:51 [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Masahiro Yamada
2017-10-13 9:51 ` [U-Boot] [PATCH v2 1/3] kbuild: Get rid of KBUILD_STR Masahiro Yamada
2017-10-13 9:51 ` [U-Boot] [PATCH v2 2/3] kbuild: add stringify helper to quote a string passed to C files Masahiro Yamada
@ 2017-10-13 9:51 ` Masahiro Yamada
2017-10-13 12:11 ` [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Tom Rini
3 siblings, 0 replies; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 9:51 UTC (permalink / raw)
To: u-boot
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
# ---------------------------------------------------------------------------
--
2.7.4
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 9:51 [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Masahiro Yamada
` (2 preceding siblings ...)
2017-10-13 9:51 ` [U-Boot] [PATCH v2 3/3] kbuild: redefine __FILE__ as relative path from $(srctree) if possible Masahiro Yamada
@ 2017-10-13 12:11 ` Tom Rini
2017-10-13 12:21 ` Masahiro Yamada
3 siblings, 1 reply; 11+ messages in thread
From: Tom Rini @ 2017-10-13 12:11 UTC (permalink / raw)
To: u-boot
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 at 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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171013/c896c93d/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 12:11 ` [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__ Tom Rini
@ 2017-10-13 12:21 ` Masahiro Yamada
2017-10-13 13:53 ` Tom Rini
0 siblings, 1 reply; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 12:21 UTC (permalink / raw)
To: u-boot
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 at 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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 12:21 ` Masahiro Yamada
@ 2017-10-13 13:53 ` Tom Rini
2017-10-13 17:37 ` Masahiro Yamada
2017-10-13 18:35 ` Masahiro Yamada
0 siblings, 2 replies; 11+ messages in thread
From: Tom Rini @ 2017-10-13 13:53 UTC (permalink / raw)
To: u-boot
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 at 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/..
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171013/82f1380c/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 13:53 ` Tom Rini
@ 2017-10-13 17:37 ` Masahiro Yamada
2017-10-13 18:35 ` Masahiro Yamada
1 sibling, 0 replies; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 17:37 UTC (permalink / raw)
To: u-boot
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 at 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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 13:53 ` Tom Rini
2017-10-13 17:37 ` Masahiro Yamada
@ 2017-10-13 18:35 ` Masahiro Yamada
2017-10-13 21:39 ` Tom Rini
1 sibling, 1 reply; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-13 18:35 UTC (permalink / raw)
To: u-boot
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 at 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...
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 18:35 ` Masahiro Yamada
@ 2017-10-13 21:39 ` Tom Rini
2017-10-15 9:48 ` Masahiro Yamada
0 siblings, 1 reply; 11+ messages in thread
From: Tom Rini @ 2017-10-13 21:39 UTC (permalink / raw)
To: u-boot
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 at 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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171013/af60f121/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH v2 0/3] kbuild: always use relative path for __FILE__
2017-10-13 21:39 ` Tom Rini
@ 2017-10-15 9:48 ` Masahiro Yamada
0 siblings, 0 replies; 11+ messages in thread
From: Masahiro Yamada @ 2017-10-15 9:48 UTC (permalink / raw)
To: u-boot
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 at 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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 11+ messages in thread