|
[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 |