Re: [PATCH] zap linking-only option from EMBEDDED_EXTRA_CFLAGS

From: Andrew Cooper <Andrew.Cooper3@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Wei Liu <wl@xen.org>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [PATCH] zap linking-only option from EMBEDDED_EXTRA_CFLAGS
Date: Tue, 27 Sep 2022 14:29:34 +0000	[thread overview]
Message-ID: <7eab9645-0c7e-e171-870b-814c330fac08@citrix.com> (raw)
In-Reply-To: <YzMFLffjWLzz4nW6@MacBook-Air-de-Roger.local>

On 27/09/2022 15:14, Roger Pau Monne wrote:
> On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
>> While I was suspicious of the compiler issuing a diagnostic about an
>> unused linking-only option when not doing any linking, I did check this
>> with a couple of gcc versions only, but not with Clang. (Oddly enough at
>> least older Clang versions complain about the use of '-nopie' now that
>> we actually use '-no-pie'.) Filter out the problematic option in all
>> cases where the variable is consumed for compilation only (which right
>> now is everywhere).
>>
>> Fixes: ecd6b9759919 ("Config.mk: correct PIE-related option(s) in EMBEDDED_EXTRA_CFLAGS")
>> Reported-by: Stefano Stabellini <sstabellini@kernel.org>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Arguably with all users of EMBEDDED_EXTRA_CFLAGS using these just for
>> compiling, the option could be omitted from that variable right away.
>> But if any compile-and-link-in-one-go use appeared, there would be an
>> issue.
> Is it feasible to have compile-and-link-in-one-go in one use feasible
> with what we consider embedded (firmware or kernel like binaries).  I
> would expect those to always require a linker script and a separate
> linking step.

As I've expressed several times previously, the entire variable is bogus.

Just because we do have several things which are built as
non-freestanding, doesn't mean they share a common CLFLAGS environment.

PIE is very specific to the intended use, and blindly disabling the
stack protector isn't safe either.  It only works because none of our
freestanding environments have gone to the effort of adding stack
protector support.

-fno-exceptions is furthermore bogus in CLFLAGS, as its a CXXFLAG only.

And no, this mess can't plausibly be used for a compile and link in one
go.  Filtering out a non-CFLAG from the collection at every call site is
nonsense.

~Andrew