On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek wrote: > > On Tue, Aug 4, 2020 at 2:09 AM 'Nick Desaulniers' via Clang Built > Linux wrote: > > > > On Wed, May 27, 2020 at 6:53 AM Arnd Bergmann wrote: > > > > > > When using the clang integrated assembler, we get a reference > > > to __force_order that should normally get ignored in a few > > > rare cases: > > > > > > ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko] undefined! > > > > > > Add a 'static' definition so any file in which this happens can > > > have a local copy. > > > > > > Signed-off-by: Arnd Bergmann > > > > Hi Arnd, > > Looks like > > $ ARCH=i386 make CC=clang LLVM_IAS=1 -j71 > > defconfig+CONFIG_X86_POWERNOW_K6=m > > is the simplest reproducer. > > > > If I run > > $ llvm-readelf -s drivers/cpufreq/powernow-k6.o | grep __force_order > > 39: 00000000 0 NOTYPE GLOBAL DEFAULT UND __force_order > > we can indeed see an undefined reference to __force_order. > > > > If I build the .s file via > > $ ARCH=i386 make CC=clang LLVM_IAS=1 -j71 drivers/cpufreq/powernow-k6.s > > the only reference I see to __force_order is: > > 979 .addrsig_sym __force_order > > > > which is created by Clang's implicit -faddr-sig. If I disable that > > for this file via: > > > > ```diff > > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > > index f1b7e3dd6e5d..87d655d5af49 100644 > > --- a/drivers/cpufreq/Makefile > > +++ b/drivers/cpufreq/Makefile > > @@ -28,6 +28,9 @@ obj-$(CONFIG_X86_ACPI_CPUFREQ) += > > acpi-cpufreq.o > > obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o > > obj-$(CONFIG_X86_PCC_CPUFREQ) += pcc-cpufreq.o > > obj-$(CONFIG_X86_POWERNOW_K6) += powernow-k6.o > > +ifdef CONFIG_CC_IS_CLANG > > +CFLAGS_powernow-k6.o += -fno-addrsig > > +endif > > obj-$(CONFIG_X86_POWERNOW_K7) += powernow-k7.o > > obj-$(CONFIG_X86_LONGHAUL) += longhaul.o > > obj-$(CONFIG_X86_E_POWERSAVER) += e_powersaver.o > > ``` > > then the module links without error, and we get no hits for > > __force_order from llvm-readelf -s. This makes me think there may be > > a bug in Clang generating address significance tables for global > > variables that are otherwise unused, resulting in such linkage > > failures. +pcc@ for that. > > > > I ran a creduce job on drivers/cpufreq/powernow-k6.i where I'd compile > > twice, one with the implicit default value of -faddr-sig and look for > > the undefined __force_order, and again with -fno-addrsig and ensure > > there was no undefined __force_order, which coughed up: > > extern int __force_order; > > int a(void) { asm("" : "=m"(__force_order)); return 0; } > > as the bare minimum for an address significant table. > > https://godbolt.org/z/cjfaqM > > > > I'll bet this is coming from the call to read_cr0() in > > powernow_k6_set_cpu_multiplier(). If __force_order is defined in > > arch/x86/boot/compressed/pgtable_64.c, then I'm not sure it's a good > > idea to build drivers/cpufreq/powernow-k6.c as a kernel module > > (CONFIG_X86_POWERNOW_K6=m) vs statically compiled in. Wouldn't > > __force_order need to be EXPORT'ed for kernel modules to use it > > safely? > > > > > --- > > > arch/x86/boot/compressed/pgtable_64.c | 2 ++ > > > arch/x86/include/asm/special_insns.h | 7 +++++++ > > > 2 files changed, 9 insertions(+) > > > > > > diff --git a/arch/x86/boot/compressed/pgtable_64.c b/arch/x86/boot/compressed/pgtable_64.c > > > index c8862696a47b..8595194cea41 100644 > > > --- a/arch/x86/boot/compressed/pgtable_64.c > > > +++ b/arch/x86/boot/compressed/pgtable_64.c > > > @@ -12,7 +12,9 @@ > > > * It is not referenced from the code, but GCC < 5 with -fPIE would fail > > > * due to an undefined symbol. Define it to make these ancient GCCs work. > > > */ > > > +#ifndef CONFIG_CC_IS_CLANG > > > unsigned long __force_order; > > > +#endif > > > > > > #define BIOS_START_MIN 0x20000U /* 128K, less than this is insane */ > > > #define BIOS_START_MAX 0x9f000U /* 640K, absolute maximum */ > > > diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h > > > index 82436cb04ccf..7081e587c1ea 100644 > > > --- a/arch/x86/include/asm/special_insns.h > > > +++ b/arch/x86/include/asm/special_insns.h > > > @@ -16,8 +16,15 @@ > > > * A memory clobber would solve the problem, but would prevent reordering of > > > * all loads stores around it, which can hurt performance. Solution is to > > > * use a variable and mimic reads and writes to it to enforce serialization > > > + * > > > + * Clang sometimes fails to kill the reference to the dummy variable, so > > > + * provide an actual copy. > > > */ > > > +#ifdef CONFIG_CC_IS_CLANG > > > +static unsigned long __force_order; > > > +#else > > > extern unsigned long __force_order; > > > +#endif > > > > > > void native_write_cr0(unsigned long val); > > > > > > -- > > > 2.26.2 > > > > > Thanks for the proposal. > > I have adapted it to fit my patchset against Linux v5.8. > > Both Debian's GCC-10 and a snapshot version of LLVM toolchain > v11.0.0-rc1+ seems to be OK. > > MAKE_OPTS="V=1 -j3 CC=gcc-10 LD=ld.bfd" > make $MAKE_OPTS arch/x86/kernel/cpu/common.o > > MAKE_OPTS="V=1 -j3 HOSTCC=clang-11 HOSTCXX=clang++-11 HOSTLD=ld.lld-11 > HOSTAR=llvm-ar-11 CC=clang-11 LD=ld.lld-11 AR=llvm-ar-11 NM=llvm-nm-11 > OBJCOPY=llvm-objcopy-11 OBJDUMP=llvm-objdump-11 OBJSIZE=llvm-size-11 > READELF=llvm-readelf-11 STRIP=llvm-strip-11 LLVM_IAS=1" > make $MAKE_OPTS arch/x86/kernel/cpu/common.o > > I can send both object files if desired. > > I will do a full kernel-build to see if I am able to build the > VirtualBox out-of-tree kernel-modules. > Yupp, OK. I was able to boot FreeDOS 1.2 VM in VirtualBox GUI. My kernel-config and dmesg-output are attached. - Sedat - P.S.: Logs root@iniza:~# systemctl status virtualbox.service ● virtualbox.service - LSB: VirtualBox Linux kernel module Loaded: loaded (/etc/init.d/virtualbox; generated) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) root@iniza:~# systemctl start virtualbox.service root@iniza:~# systemctl status virtualbox.service ● virtualbox.service - LSB: VirtualBox Linux kernel module Loaded: loaded (/etc/init.d/virtualbox; generated) Active: active (exited) since Fri 2020-08-14 23:04:08 CEST; 1s ago Docs: man:systemd-sysv-generator(8) Process: 2289 ExecStart=/etc/init.d/virtualbox start (code=exited, status=0/SUCCESS) Aug 14 23:04:07 iniza systemd[1]: Starting LSB: VirtualBox Linux kernel module... Aug 14 23:04:08 iniza virtualbox[2289]: Loading VirtualBox kernel modules... vboxdrv vboxnetflt vboxnetadp. Aug 14 23:04:08 iniza systemd[1]: Started LSB: VirtualBox Linux kernel module. root@iniza:~# dmesg -T | tail [Fr Aug 14 23:03:31 2020] wlp1s0: associate with 50:d4:f7:2e:17:da (try 1/3) [Fr Aug 14 23:03:31 2020] wlp1s0: RX AssocResp from 50:d4:f7:2e:17:da (capab=0x411 status=0 aid=1) [Fr Aug 14 23:03:31 2020] wlp1s0: associated [Fr Aug 14 23:03:31 2020] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready [Fr Aug 14 23:04:08 2020] vboxdrv: loading out-of-tree module taints kernel. [Fr Aug 14 23:04:08 2020] vboxdrv: Found 4 processor cores [Fr Aug 14 23:04:08 2020] vboxdrv: TSC mode is Invariant, tentative frequency 1600198501 Hz [Fr Aug 14 23:04:08 2020] vboxdrv: Successfully loaded version 6.1.12_Debian (interface 0x002d0001) [Fr Aug 14 23:04:08 2020] VBoxNetFlt: Successfully started. [Fr Aug 14 23:04:08 2020] VBoxNetAdp: Successfully started. root@iniza:~# lsmod | grep vbox vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 532480 2 vboxnetadp,vboxnetflt - EOT -