Hi,
Xu Zhen <[email protected]> reported on Bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=218825) thinlto build directory problem (especially on
DKMS modules). He wrote:
> In Makefile, the ld flag `--thinlto-cache-dir' is set to
> `$(extmod_prefix).thinlto-cache'. But at that time, the variable extmod_prefix
> had not been assigned yet. Therefore, the thinlto cache dir is always created
> in the current directory.
>
> Even worse, the cache dir cannot be deleted when executing `make clean'. This
> is because its path was written as `$(KBUILD_EXTMOD)/.thinlto-cache' in the
> clean: target.
>
> Some users have been troubled by it: https://github.com/dell/dkms/issues/292
>
> This bug was introduced by commit dc5723b02e523b2c4a68667f7e28c65018f7202f
Thanks.
--
An old man doll... just what I always wanted! - Clara
+CC: Nathan
On Sat, May 11, 2024 at 8:18 PM Bagas Sanjaya <[email protected]> wrote:
>
> Hi,
>
> Xu Zhen <[email protected]> reported on Bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=218825) thinlto build directory problem (especially on
> DKMS modules). He wrote:
>
> > In Makefile, the ld flag `--thinlto-cache-dir' is set to
> > `$(extmod_prefix).thinlto-cache'. But at that time, the variable extmod_prefix
> > had not been assigned yet. Therefore, the thinlto cache dir is always created
> > in the current directory.
> >
> > Even worse, the cache dir cannot be deleted when executing `make clean' This
> > is because its path was written as `$(KBUILD_EXTMOD)/.thinlto-cache' in the
> > clean: target.
> >
> > Some users have been troubled by it: https://github.com/dell/dkms/issues/292
> >
> > This bug was introduced by commit dc5723b02e523b2c4a68667f7e28c65018f7202f
I agree this is a bug.
line 945:
KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache
line 1034:
KBUILD_LDFLAGS += $(call ld-option,--no-warn-rwx-segments)
line 1095:
export extmod_prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)
$(call ld-option ) at line 1034 adds --thinlto-cache-dir=.thinlto-cache
because --thinlto-cache-dir=$(extmod_prefix).thinlto-cache was added
at line 945, but $(extmod_prefix) is empty until it is defined
at line 1095.
However, the offending line was already removed for another issue.
See the following in linux-next:
Author: Nathan Chancellor <[email protected]>
Date: Wed May 1 15:55:25 2024 -0700
kbuild: Remove support for Clang's ThinLTO caching
If --thinlto-cache-dir comes back,
I hope Nathan will take care of this issue.
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
--
Best Regards
Masahiro Yamada
On Sun, May 12, 2024 at 10:04 PM Masahiro Yamada <[email protected]> wrote:
>
> +CC: Nathan
>
>
> On Sat, May 11, 2024 at 8:18 PM Bagas Sanjaya <[email protected]> wrote:
> >
> > Hi,
> >
> > Xu Zhen <[email protected]> reported on Bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=218825) thinlto build directory problem (especially on
> > DKMS modules). He wrote:
> >
> > > In Makefile, the ld flag `--thinlto-cache-dir' is set to
> > > `$(extmod_prefix).thinlto-cache'. But at that time, the variable extmod_prefix
> > > had not been assigned yet. Therefore, the thinlto cache dir is always created
> > > in the current directory.
> > >
> > > Even worse, the cache dir cannot be deleted when executing `make clean'. This
> > > is because its path was written as `$(KBUILD_EXTMOD)/.thinlto-cache' in the
> > > clean: target.
> > >
> > > Some users have been troubled by it: https://github.com/dell/dkms/issues/292
> > >
> > > This bug was introduced by commit dc5723b02e523b2c4a68667f7e28c65018f7202f
>
>
> I agree this is a bug.
>
>
>
>
> line 945:
> KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache
>
>
> line 1034:
> KBUILD_LDFLAGS += $(call ld-option,--no-warn-rwx-segments)
This one is probably OK because it is guarded by CONFIG_LD_IS_BFD,
while LTO requires LD_IS_LLD.
I see another ld-option at 1043.
LDFLAGS_vmlinux += $(call ld-option,--pack-dyn-relocs=relr,-z
pack-relative-relocs)
Maybe, this is related to the issue
(although I did not attempt to reproduce it).
--
Best Regards
Masahiro Yamada