[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] zap linking-only option from EMBEDDED_EXTRA_CFLAGS
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |