Created attachment 4424 [details]
stap.log

The following command can also reproduce the issue:

$ stap -ve 'probe oneshot { println("hello world") }'

There is no such issue on other BSPs (mpc8315e-rdb and edgerouter).

This just affected our transition of qemuarm to armv7a as well :(

its possible that it was using -march option to set cpu but now we do not pass -march any longer and use -mcpu to do the job. I think thats where the disconnect is. It then ends up selecting armv5 or something for cpu and that will produce such errors.

Error happens because -march=armv5t option is passed to compiler

I was able to reproduce the issue. It is not SystemTap problem per se. For
given h/w, gcc, and kernel sources system cannot compile kernel module that
uses atomic functions. For example:

Using atomic functions test case:

root@beaglebone-yocto:~/m# cat hello.c
#include <linux/module.h>
#include <linux/atomic.h>

static atomic_t my_counter = ATOMIC_INIT(1);

int
init_module (void)
{
    atomic_inc(&my_counter);
    return 0;
}

void
cleanup_module(void)
{
}

MODULE_LICENSE("GPL");
root@beaglebone-yocto:~/m# cat Makefile 
obj-m := hello.o
root@beaglebone-yocto:~/m# make -C /usr/src/kernel V=1 M=/home/root/m
make: Entering directory '/lib/modules/4.18.9-yocto-standard/build'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (                \
echo >&2;                                                       \
echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";      \
echo >&2 ;                                                      \
/bin/false)
mkdir -p /home/root/m/.tmp_versions ; rm -f /home/root/m/.tmp_versions/*
make -f ./scripts/Makefile.build obj=/home/root/m
(cat /dev/null;   echo kernel//home/root/m/hello.ko;) > /home/root/m/modules.order
  gcc -Wp,-MD,/home/root/m/.hello.o.d  -nostdinc -isystem /usr/lib/gcc/arm-poky-linux-gnueabi/8.2.0/include -I./arch/arm/include -I./arch/arm/include/generated  -I./include -I./arch/arm/include/uapi -I./arch/arm/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -DCC_HAVE_ASM_GOTO -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra -mabi=aapcs-linux -mfpu=vfp -funwind-tables -marm -Wa,-mno-warn-deprecated -D__LINUX_ARM_ARCH__=7 -march=armv5t -Wa,-march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned  -DMODULE  -DKBUILD_BASENAME='"hello"' -DKBUILD_MODNAME='"hello"' -c -o /home/root/m/hello.o /home/root/m/hello.c
/tmp/ccbSfHhk.s: Assembler messages:
/tmp/ccbSfHhk.s:58: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccbSfHhk.s:60: Error: selected processor does not support `strex r1,r2,[r3]' in ARM mode
make[1]: *** [scripts/Makefile.build:324: /home/root/m/hello.o] Error 1
make: *** [Makefile:1504: _module_/home/root/m] Error 2
make: Leaving directory '/lib/modules/4.18.9-yocto-standard/build'

It happens because '-march=armv5t' is passed to gcc. That in turns triggered
by CONFIG_CPU_32v7, the following cc-option suggested in arch/arm/Makefile:

arch-$(CONFIG_CPU_32v7)         =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)

And gcc in the system does not understand first choice "-march=armv7-a"

root@beaglebone-yocto:~# gcc -march=armv7-a -c foo.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

and as result fall backs to second choice with -march=armv5t.

It looks like gcc is configured with '-march=armv7-a+fp'

root@beaglebone-yocto:~# gcc -v -c foo.c 2>&1 | grep COLLECT_GCC_OPTIONS | head -1
COLLECT_GCC_OPTIONS='-v' '-c'  '-mfloat-abi=hard' '-mtls-dialect=gnu' '-marm' '-march=armv7-a+fp'
root@beaglebone-yocto:~# gcc -march=armv7-a+fp -c foo.c
root@beaglebone-yocto:~# 

The following hack helps:

root@beaglebone-yocto:/usr/src/kernel# cat patches/arm-makefile-fix.patch 
Index: kernel/arch/arm/Makefile
===================================================================
--- kernel.orig/arch/arm/Makefile
+++ kernel/arch/arm/Makefile
@@ -67,7 +67,7 @@ KBUILD_CFLAGS += $(call cc-option,-fno-i
 # macro, but instead defines a whole series of macros which makes
 # testing for a specific architecture or later rather impossible.
 arch-$(CONFIG_CPU_32v7M)       =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
-arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
+arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a+fp,-march=armv5t -Wa$(comma)-march=armv7-a)
 arch-$(CONFIG_CPU_32v6)                =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
 # Only override the compiler option if ARMv6. The ARMv6K extensions are
 # always available in ARMv7

Checking corresponding kernel host build options used there
to build kernel source are '-march=armv7-a -msoft-float' since
in cross compilation mode gcc cannot check underlying CPU, so it
does not complain.

Also if I pass '-march=armv7-a -msoft-float' to gcc invocation
on target it works fine, recall that just '-march=armv7-a' failed:

root@beaglebone-yocto:~# gcc -march=armv7-a -msoft-float -c foo.c
root@beaglebone-yocto:~# 

I.e one way to look at

root@beaglebone-yocto:/usr/src/kernel# cat patches/arm-makefile-fix.patch
Index: kernel/arch/arm/Makefile
===================================================================
--- kernel.orig/arch/arm/Makefile
+++ kernel/arch/arm/Makefile
@@ -67,7 +67,7 @@ KBUILD_CFLAGS += $(call cc-option,-fno-i
 # macro, but instead defines a whole series of macros which makes
 # testing for a specific architecture or later rather impossible.
 arch-$(CONFIG_CPU_32v7M)       =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
-arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
+arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a -msoft-float,-march=armv5t -Wa$(comma)-march=armv7-a)
 arch-$(CONFIG_CPU_32v6)                =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
 # Only override the compiler option if ARMv6. The ARMv6K extensions are
 # always available in ARMv7

I believe the issue is that beaglebone toolchain and sysroot is
misconfigured: it is configured with hard float (qemuarm) but beaglebone
CPU does not have it. Kernel emulates all hard float instructions so
we don't see any effect of it, but it would be very slow. As atomic instructions in KLM compilation is gcc default setting in this case.

I believe if beaglebone tune would be switched to soft floating point this
issue goes away. Again it does not look as SystemTap bug to me.

I managed to narrow this down a bit.

root@qemuarm:/usr/src/kernel# env -uARCH -uKBUILD_EXTMOD -uCROSS_COMPILE -uKBUILD_IMAGE -uKCONFIG_CONFIG -uINSTALL_PATH -uLD_LIBRARY_PATH PATH=/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin make -C /lib/modules/4.19.19-yocto-standard/build M=/tmp/staptcNU6M modules CONFIG_DEBUG_INFO= CONFIG_STACK_VALIDATION= ARCH=arm stap_4321_src.i --no-print-directory -j2 V=1
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;							\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;							\
/bin/false)
mkdir -p /tmp/staptcNU6M/.tmp_versions ; rm -f /tmp/staptcNU6M/.tmp_versions/*
make -f ./scripts/Makefile.build obj=/tmp/staptcNU6M
(cat /dev/null;   echo kernel//tmp/staptcNU6M/stap_4321.ko;) > /tmp/staptcNU6M/modules.order
  gcc -Wp,-MD,/tmp/staptcNU6M/.stap_4321_src.o.d  -nostdinc -isystem /usr/lib/gcc/arm-poky-linux-gnueabi/8.3.0/include -I./arch/arm/include -I./arch/arm/include/generated  -I./include -I./arch/arm/include/uapi -I./arch/arm/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -DCC_HAVE_ASM_GOTO -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra -mabi=aapcs-linux -mfpu=vfp -funwind-tables -marm -Wa,-mno-warn-deprecated -D__LINUX_ARM_ARCH__=7 -march=armv5t -Wa,-march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -pg -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -Iinclude2/asm/mach-default -I/lib/modules/4.19.19-yocto-standard/build -include /tmp/staptcNU6M/stapconf_4321.h -D "STP_NO_VELREL_CHECK" -freorder-blocks -fasynchronous-unwind-tables -Wframe-larger-than=512 -fno-ipa-icf -Wno-unused -Wno-tautological-compare -Werror -I/usr/share/systemtap/runtime  -DMODULE  -DKBUILD_BASENAME='"stap_4321_src"' -DKBUILD_MODNAME='"stap_4321"' -c -o /tmp/staptcNU6M/stap_4321_src.o /tmp/staptcNU6M/stap_4321_src.c
/tmp/ccaE9CMG.s: Assembler messages:
/tmp/ccaE9CMG.s:49: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccaE9CMG.s:52: Error: architectural extension `mp' is not allowed for the current b

(which was from running the stap command with -v -v -v -k and then being able to run the command individually)

Note that it says armv5t above.

That comes from:

arch/arm/Makefile:
arch-$(CONFIG_CPU_32v7)		=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)

root@qemuarm:/usr/src/kernel# gcc -march=armv7-a /tmp/staptcNU6M/stap_4321_aux_0.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU

which makes me wonder if cc-option fails unless -mfpu-vfp is on the commandline too.

Since we know our gcc supports this option I'm going to try with:

arch-$(CONFIG_CPU_32v7)		=-D__LINUX_ARM_ARCH__=7 -march=armv7-a -Wa$(comma)-march=armv7-a

Victor, looks like we reached the same conclusion of where the issue is (I was on a flight and had a look so I hadn't seen your comment until now).

I think this may be a glitch in the way cc-option works in the kernel, I'm going to test with it removed...

Confirmed the test passes if the option is removed.

Hi Richard,

> Confirmed the test passes if the option is removed.

Is it on beaglebone or qemuarm?. It seems it is on qemuarm. Note
original issue was reported on beaglebone, and as per my notes issue there
is because beaglebone CPU does not h/w floating point. As per my notes
on beaglebone option that you suggest won't work. gcc will complain
that gcc is not configured with soft float (unless it has changed since
time I looked at it; gcc config could be seen with 'gcc -v -c foo.c 2>&1 | grep COLLECT_GCC_OPTIONS | head -1' command).

If you issue is on qemuarm, your result is a bit weird. I wonder why cc-option
macro does not really work. My understanding that kernel makefile will try
to compile test file with '-march=armv7-a', if it is successful it will
just use it, otherwise it will try '-march=armv5t -Wa$(comma)-march=armv7-a'

I.e difference between
'$(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) and
direct option you tried "-D__LINUX_ARM_ARCH__=7 -march=armv7-a -Wa$(comma)-march=armv7-a" would be "-Wa$(comma)-march=armv7-a" (assuming that
cc-option works as expected), which should not really matter unless binutils
not configured correctly. It would be interesting to dig in why cc-option
does not work as expected.

Is it qemuarm on latest committed OE, or there are some additional changes.
If I could reproduce it, I can try to look at it tomorrow.

Going back to beaglebone issue I think your fix won't help unless default is
soft float in armv7-a case.

Note my suggestion to use soft float tune for beaglebone sysroot is actually
problematic if qemuarm target is configured with hard float, since in this
case artifacts cannot be shared.

Thanks,
Victor

Richard, I've read your notes really carefully :) just after my reply :(

What changes did you do? Did you just add -msoft-float to compilation
line? Apparently it looks like qemuarm also cannot execute hard
float instructions, the same as beaglebone (it is bit strange though because
it is used to work, ?was qemu config changed?). Now, it begs the question
why arm default tune has hard float on, if both primary testing
targets (qemuarm and beaglebone) cannot execute hard float instruction
and kernel needs to emulate them.

we configure target gcc with qualified architecture with extentions e.g. --with-arch=armv7ve+fp when call convention hard is used in tunes. So ideally one does not need to specify -march option if target is same  ( native ) when building something on target. However, when we specify -march=armv7-a then we want to override the defaults but this option means that we do not spefify floating-point support, but gcc is configured for hard-floating calling convention which requires fp to work. Thats why you get the error.

So options are either use -march=armv7-a -mfloat-abi=softfp which will make it use soft calling convention or -march=armv7-a+fp ( or -march=armv7-a -mfpu=vfp) which will indicate that we do have fp.

so the Makefile should be changed to use one of the above options. e.g.

arch-$(CONFIG_CPU_32v7)		=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a+fp,-march=armv5t -Wa$(comma)-march=armv7-a)

Khem, thank you for clarification.

Now I understand why dropping cc-option works for Richard (answering my
question in Comment 9), it happens that -msoft-float is passed to arm
kernel compilation unconditionally latter (kernel always built with
soft-float), so when cc-option makefile macro call is dropped, it does not
run check that -march=armv7-a option is supported by compiler but when
it really compiles code -msoft-float is added and everything goes fine.

I think better (possibly upstreamable) option is to keep cc-option macro
call but add -msoft-float to it. I.e:

arch-$(CONFIG_CPU_32v7)         =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a -msoft-float,-march=armv5t -Wa$(comma)-march=armv7-a)

In this case check will go through to and this option will be selected.

Let me send this patch upstream and see what they say.

Khem, by any chance, do you know gcc commit that introduced
-march=armv7-a+fp? It would be good to have it referenced. Also was "+fp"
variant was added only to -march=armv7-a or we have similar other variants
like -march=armv6+fp or -march=armv6k+fp? ... just to understand whether
there are any other cases that would be in similar situation.

Found what gcc commit introduced '-march=armv7-a+fp'

Posted proposed fix upstream on arm linux kernel mailing list:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637809.html

We resolved this at least for our usecases in the kernel:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=75d744c26b2e34e433a80f2478e3d2bf85126672
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cda5d455992e1aceae911178b7143b67e0ac29cc

Upstream discussions are ongoing.

I still got the same error in 2.7 M3 RC1 testing.
Image location: https://autobuilder.yocto.io/pub/releases/yocto-2.7_M3.rc1/machines/beaglebone-yocto/
Git rev: master/753e2a0ede4449917c75353b57f13bbafe70fac8

Error message:

$ stap -ve 'probe oneshot { println("hello world") }'

WARNING: Kernel function symbol table missing [man warning::symbols]
Pass 1: parsed user script and 459 library scripts using 42108virt/37924res/4500shr/33676data kb, in 2580usr/460sys/3616real ms.
Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 42768virt/38932res/4828shr/34336data kb, in 80usr/0sys/95real ms.
Pass 3: translated to C into "/tmp/stappPMudO/stap_6d8af741ae46dbcad962a6c14afe8f23_994_src.c" using 42768virt/39284res/5148shr/34336data kb, in 0usr/0sys/3real ms.
/tmp/ccYoCHW4.s: Assembler messages:
/tmp/ccYoCHW4.s:964: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:1046: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:1105: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:1182: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:2185: Error: selected processor does not support `ldrex r0,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2188: Error: selected processor does not support `strexeq ip,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2275: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:2277: Error: selected processor does not support `strex r1,r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:2288: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:2290: Error: selected processor does not support `strex r1,r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:2333: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:2382: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:2384: Error: selected processor does not support `strex r2,r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:2440: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:2442: Error: selected processor does not support `strex r2,r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:2492: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:2527: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:2540: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:2561: Error: selected processor does not support `ldrex r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:2563: Error: selected processor does not support `strex r2,r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:2612: Error: selected processor does not support `ldrex r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2614: Error: selected processor does not support `strex r0,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2680: Error: selected processor does not support `ldrex r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2682: Error: selected processor does not support `strex r0,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2694: Error: selected processor does not support `ldrex r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:2696: Error: selected processor does not support `strex r0,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:3200: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:3203: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3237: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3249: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3264: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:3267: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3324: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:3327: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3362: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3374: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3391: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:3394: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:3586: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:3655: Error: selected processor does not support `ldrex r3,[r6]' in ARM mode
/tmp/ccYoCHW4.s:3657: Error: selected processor does not support `strex r2,r3,[r6]' in ARM mode
/tmp/ccYoCHW4.s:3756: Error: selected processor does not support `ldrex r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:3758: Error: selected processor does not support `strex r0,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:4085: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:4139: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:4181: Error: selected processor does not support `ldrex r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:4183: Error: selected processor does not support `strex r2,r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:4251: Error: selected processor does not support `ldrex r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:4253: Error: selected processor does not support `strex r2,r3,[r5]' in ARM mode
/tmp/ccYoCHW4.s:4340: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:4377: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:4379: Error: selected processor does not support `strex r2,r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:5174: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:5177: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5191: Error: selected processor does not support `dsb nsh' in ARM mode
/tmp/ccYoCHW4.s:5194: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5342: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:5344: Error: selected processor does not support `strex r1,r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:5357: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccYoCHW4.s:5387: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:5389: Error: selected processor does not support `strex r2,r3,[r4]' in ARM mode
/tmp/ccYoCHW4.s:5455: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:5457: Error: selected processor does not support `strex r1,r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:5515: Error: selected processor does not support `ldrex ip,[r2]' in ARM mode
/tmp/ccYoCHW4.s:5518: Error: selected processor does not support `strexeq lr,r1,[r2]' in ARM mode
/tmp/ccYoCHW4.s:5799: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5811: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5876: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5889: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:5920: Error: selected processor does not support `ldrex r2,[r3]' in ARM mode
/tmp/ccYoCHW4.s:5923: Error: selected processor does not support `strexeq r0,r1,[r3]' in ARM mode
/tmp/ccYoCHW4.s:6030: Error: selected processor does not support `ldrex r2,[r8]' in ARM mode
/tmp/ccYoCHW4.s:6033: Error: selected processor does not support `strexeq r5,r3,[r8]' in ARM mode
/tmp/ccYoCHW4.s:6094: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6107: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6150: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6164: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6269: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6282: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6342: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6356: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6403: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6416: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6461: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6475: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccYoCHW4.s:6519: Error: selected processor does not support `ldrex r8,[r2]' in ARM mode
/tmp/ccYoCHW4.s:6522: Error: selected processor does not support `strexeq r1,r3,[r2]' in ARM mode
make[1]: *** [scripts/Makefile.build:276: /tmp/stappPMudO/stap_6d8af741ae46dbcad962a6c14afe8f23_994_src.o] Error 1
make: *** [Makefile:1553: _module_/tmp/stappPMudO] Error 2
WARNING: kbuild exited with status: 2
Pass 4: compiled C into "stap_6d8af741ae46dbcad962a6c14afe8f23_994.ko" in 145300usr/14370sys/163480real ms.
Pass 4: compilation failed.  [man error::pass4]

Hi Yi,

Could you find the arm kernel Makefile that this comes from and see which options are there?

kernel/arch/arm/Makefile

should have

arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)

replaced with:

arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a -msoft-float,-march=armv5t -Wa$(comma)-march=armv7-a)

so I'm confused as to why that didn't happen?

Cheers,

Richard

Created attachment 4454 [details]
Makefile

(In reply to comment #16)
> Hi Yi,
> 
> Could you find the arm kernel Makefile that this comes from and see which
> options are there?
> 
> kernel/arch/arm/Makefile
> 
> should have
> 
> arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call
> cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
> 
> replaced with:
> 
> arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call
> cc-option,-march=armv7-a -msoft-float,-march=armv5t
> -Wa$(comma)-march=armv7-a)


Here it the line 66 - 67 in Makefile:

arch-$(CONFIG_CPU_32v7M)    =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
arch-$(CONFIG_CPU_32v7)     =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)


I have attached the full Makefile.



> 
> so I'm confused as to why that didn't happen?
> 
> Cheers,
> 
> Richard

After replaced with the following line in kernel/arch/arm/Makefile manually:

arch-$(CONFIG_CPU_32v7)                =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a -msoft-float,-march=armv5t -Wa$(comma)-march=armv7-a)

This case can pass:
RESULTS - stap.StapTest.test_stap - Testcase 1652: PASSED (180.91s)

I think I understand the problem, the SRCREV wasn't bumped for beaglebone-yocto. Kevin/Bruce?

I just sent a patch to bump the kernel for the yocto BSPs.

Thanks Kevin!

This means this should now really be fixed in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ab05f409bef45a756ee4d1034f33d6985fec9f93