On Fri, Jan 20, 2023, at 15:09, Yann Sionneau wrote:
> - Fix clean target raising an error from gcc (LIBGCC)
I had not noticed this on v1 but:
> +# Link with libgcc to get __div* builtins.
> +LIBGCC := $(shell $(CC) $(DEFAULT_OPTS) --print-libgcc-file-name)
It's better to copy the bits of libgcc that you actually need
than to include the whole thing. The kernel is in a weird
state that is neither freestanding nor the normal libc based
environment, so we generally want full control over what is
used. This is particularly important for 32-bit architectures
that do not want the 64-bit division, but there are probably
enough other cases as well.
Arnd
On Fri, Jan 20, 2023 at 03:39:22PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 20, 2023, at 15:09, Yann Sionneau wrote:
> > - Fix clean target raising an error from gcc (LIBGCC)
>
> I had not noticed this on v1 but:
>
> > +# Link with libgcc to get __div* builtins.
> > +LIBGCC := $(shell $(CC) $(DEFAULT_OPTS) --print-libgcc-file-name)
>
> It's better to copy the bits of libgcc that you actually need
> than to include the whole thing. The kernel is in a weird
It was initialy using KCONFIG_CFLAGS which do not contains valid options
when invoking the clean target.
I am not exactly sure what's needed by gcc for --print-libgcc-file-name,
my guess is that only the -march option matters, I will double check
internally with compiler peoples.
> state that is neither freestanding nor the normal libc based
> environment, so we generally want full control over what is
> used. This is particularly important for 32-bit architectures
> that do not want the 64-bit division, but there are probably
> enough other cases as well.
>
> Arnd
>
>
>
>
On Fri, Jan 20, 2023, at 15:53, Jules Maselbas wrote:
> On Fri, Jan 20, 2023 at 03:39:22PM +0100, Arnd Bergmann wrote:
>> On Fri, Jan 20, 2023, at 15:09, Yann Sionneau wrote:
>> > - Fix clean target raising an error from gcc (LIBGCC)
>>
>> I had not noticed this on v1 but:
>>
>> > +# Link with libgcc to get __div* builtins.
>> > +LIBGCC := $(shell $(CC) $(DEFAULT_OPTS) --print-libgcc-file-name)
>>
>> It's better to copy the bits of libgcc that you actually need
>> than to include the whole thing. The kernel is in a weird
> It was initialy using KCONFIG_CFLAGS which do not contains valid options
> when invoking the clean target.
>
> I am not exactly sure what's needed by gcc for --print-libgcc-file-name,
> my guess is that only the -march option matters, I will double check
> internally with compiler peoples.
>
>> state that is neither freestanding nor the normal libc based
>> environment, so we generally want full control over what is
>> used. This is particularly important for 32-bit architectures
>> that do not want the 64-bit division, but there are probably
>> enough other cases as well.
To clarify: I meant you should not include libgcc.a at all but
add the minimum set of required files as arch/kvx/lib/*.S.
Arnd