[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 27 Sep 2022 17:21:48 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DcDSxOnQG5nOtWuyCpfsnObR5HOAxZ7DEIRp6E7ww4w=; b=EmbEZ4U3OcB1T7Vy8UBtDVF0+dCw4Eg1zyOsbIkC2xd1nI77DkXTWy/sWgnos8P0PKdzRXYz3jnUU684mMKMpIHDrhHbF/KPH7a6pND84eFWCOAdd1T90VTrB7EetwfBxZu7CAHbbreMj8GXNnE3eyps2IynGXsR58d7gNWtdrrXicG4Ulal7i0uH8p8KLj21sMpLAc3RUwQPIhGrbU7+cKzHFYDyRjaRZ67COsZph3jFB0q5P6dQkeJPQdKewrD3FqMRxTABbKtQ+AcjUZ3yNr5OPFOnljxI4LOlKJTbX/ddZ40RqxuuucKa5jNrPtJjI2ZDDNDvn2by/lHTXBBkA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WSbCOFTgTxAUjArXcxHAiBx2ca6znvMJncQzW2YZNhrmMTYl9xnaDR+kj1aNmxaVOQfr+sx/eAuomFW4+dKcqh3AcP+ZFSqVT6t6LJfAfIsWFXgT+J7yttS8baFLoeICkzOPpfpk+KN8865GV3mHgZYsHEsnbIOZFiEpHOdspi7mT2kP4IlkrP6yMf7Na/5rp8S3M8taGhS6f7zoQQZ5mN6u8ITx+iMDIcXzG+3+H8ueuPJs5QL7asifoyE0hNcLA/QccsS1IY/TAcqGuyVIZXm1dCDFU/xSzqSM9RTecONHkA92T7UclAo6rCSy89KxD0y/igWkKk32XfqPNl/WVw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Tue, 27 Sep 2022 15:22:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.09.2022 17:07, Roger Pau Monné wrote:
> On Tue, Sep 27, 2022 at 04:32:27PM +0200, Jan Beulich wrote:
>> On 27.09.2022 16:14, Roger Pau Monné 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@xxxxxxxxxx>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> ---
>>>> 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.
>>
>> A separate linking step doesn't mean this needs doing via $(LD) - it
>> could also be done via $(CC). There's also no connection between using
>> a separate linking step and using a linker script - aiui the linker
>> script could also be handed to $(CC) for it to pass on the option to
>> the linker.
> 
> There's one thing that puzzles me, if we already pass -fno-pie for
> code generation, do we also need the -no-pie linker option explicitly
> added?  I would expect the compiler to be clever enough to
> automatically pass -no-pie to the linker if -fno-pie is used,
> otherwise the code won't be correctly linked?

For -pie gcc doc states: "For predictable results, you must also specify
the same set of options used for compilation (‘-fpie’, ‘-fPIE’, or model
suboptions) when you specify this linker option." I infer there's no
deriving along the lines of what you suggest.

I'm also unconvinced of there necessarily being issues with correct
linking. I can see there being executables where mismatched options
simply don't matter.

> I would rather prefer to remove the -no-pie option from
> EMBEDDED_EXTRA_CFLAGS and just add a note that users wanting to
> link-in-place need to review the set of options used.

Which then raises the question why it was added there (in a mis-spelled
manner) in the first place, years ago. That uncertainty was the only
reason why in the earlier change I didn't go and remove the option
altogether.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.