From: Arnd Bergmann <arnd@arndb.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <mmarek@suse.com>,
Nicholas Piggin <npiggin@gmail.com>,
Namhyung Kim <namhyung.with.foss@gmail.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mark Charlebois <charlebm@gmail.com>
Subject: Re: [PATCH] [SUBMITTED 20170314] [v333kbuild: disable -ffunction-sections on gcc-4.7 with ftrace
Date: Fri, 31 Mar 2017 10:48:53 +0200 [thread overview]
Message-ID: <CAK8P3a3ph=9f0LV1JoAhP8ZO4-9GGqmSmV6ajXZzw2zJPSXOPw@mail.gmail.com> (raw)
In-Reply-To: <CAK7LNASJU0rQ2oiGnoi7knNvqLGvT8FryJJ4-ap+7isHuuBnsQ@mail.gmail.com>
On Thu, Mar 30, 2017 at 5:42 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2017-03-29 18:30 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Mar 29, 2017 at 4:07 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>>> 2017-03-15 6:37 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>>> [2]
>>> This question is more technical.
>>>
>>> The cause of the problem seems that GCC warns it cannot support the
>>> two at the same time,
>>> but it does handle it as an error. So, cc-option assumes this
>>> combination is OK.
>>>
>>> Is it a good idea to add -Werror to cc-option checking?
>>
>> Hmm, I've actually been running with that change as a side-effect
>> of having the llvmlinux patches applied, which contain this one:
>>
>> commit 03497934e211325fc2913476897daf7a5ddb008a
>> Author: Mark Charlebois <charlebm@gmail.com>
>> Date: Mon Sep 22 14:33:05 2014 -0700
>>
>> kbuild, LLVMLinux: Add -Werror to cc-option to support clang
>>
>> Clang will warn about unknown warnings but will not return false
>> unless -Werror is set. GCC will return false if an unknown
>> warning is passed.
>>
>> Adding -Werror make both compiler behave the same.
>>
>> Signed-off-by: Mark Charlebois <charlebm@gmail.com>
>> Signed-off-by: Behan Webster <behanw@converseincode.com>
>> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
>>
>> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
>> index 285acc57c0a4..3629bd9c7e79 100644
>> --- a/scripts/Kbuild.include
>> +++ b/scripts/Kbuild.include
>> @@ -116,12 +116,12 @@ CC_OPTION_CFLAGS = $(filter-out
>> $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS))
>> # Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
>>
>> cc-option = $(call try-run,\
>> - $(CC) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) $(1) -c -x c
>> /dev/null -o "$$TMP",$(1),$(2))
>> + $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) $(1) -c
>> -x c /dev/null -o "$$TMP",$(1),$(2))
>>
>> # cc-option-yn
>> # Usage: flag := $(call cc-option-yn,-march=winchip-c6)
>> cc-option-yn = $(call try-run,\
>> - $(CC) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) $(1) -c -x c
>> /dev/null -o "$$TMP",y,n)
>> + $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) $(1) -c
>> -x c /dev/null -o "$$TMP",y,n)
>>
>> # cc-option-align
>> # Prefix align with either -falign or -malign
>> @@ -131,7 +131,7 @@ cc-option-align = $(subst -functions=0,,\
>> # cc-disable-warning
>> # Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable)
>> cc-disable-warning = $(call try-run,\
>> - $(CC) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -W$(strip $(1))
>> -c -x c /dev/null -o "$$TMP",-Wno-$(strip $(1)))
>> + $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -W$(strip
>> $(1)) -c -x c /dev/null -o "$$TMP",-Wno-$(strip $(1)))
>>
>> # cc-name
>> # Expands to either gcc or clang
>>
>> This is identical to your version, except it applies the same
>> thing to cc-disable-warning.
>
> Ah, I see.
>
> I'm also moving
> KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
> below
> CC_FLAGS_FTRACE := -pg
> to fix the warning.
>
>
>
>
>> I think this is good to get merged,
>> and there are probably a couple of other patches in that series
>> that we may want to look at again.
>
>
> I agree.
>
>
> At least, 03497934e21 looks good to be merged.
> (I need to get access to Mark, and ask him to send this patch.)
>
> Then, swap the -ffunction-sections and -pg order.
>
> I hope this will make you and clang guys happy.
I may have a number of clang related patches in the future,
and can also forward this patch. I suspect that Mark (added to
Cc) is currently not able to send a tested patch for the latest
kernel, he worked on it in 2014, but I don't think he's following
llvmlinux at the moment.
Arnd
next prev parent reply other threads:[~2017-03-31 8:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-14 21:33 [PATCH] [v2] kbuild: disable -ffunction-sections on gcc-4.7 with ftrace Arnd Bergmann
2017-03-14 21:35 ` [PATCH] [v333kbuild: " Arnd Bergmann
2017-03-14 21:37 ` [PATCH] [SUBMITTED 20170314] " Arnd Bergmann
2017-03-29 2:07 ` Masahiro Yamada
2017-03-29 9:30 ` Arnd Bergmann
2017-03-30 15:42 ` Masahiro Yamada
2017-03-31 8:48 ` Arnd Bergmann [this message]
[not found] ` <CAFzeTN3-=a6n-PEKP5ssCUszYYPu5R5_6uf9DEdptPKEuWOsrQ@mail.gmail.com>
2017-03-31 20:39 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK8P3a3ph=9f0LV1JoAhP8ZO4-9GGqmSmV6ajXZzw2zJPSXOPw@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=charlebm@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.com \
--cc=namhyung.with.foss@gmail.com \
--cc=npiggin@gmail.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).