On 10/24/19 11:31 AM, Ilya Leoshkevich wrote: >> Am 24.10.2019 um 19:49 schrieb Yonghong Song <yhs@xxxxxx>: >> >> >> >> On 10/24/19 9:04 AM, Ilya Leoshkevich wrote: >>>> Am 23.10.2019 um 03:35 schrieb Prabhakar Kushwaha <prabhakar.pkin@xxxxxxxxx>: >>>> >>>> >>>> Adding other mailing list, folks... >>>> >>>> Hi All, >>>> >>>> I am trying to build kselftest on Linux-5.4 on ubuntu 18.04. I installed >>>> LLVM-9.0.0 and Clang-9.0.0 from below links after following steps from >>>> [1] because of discussion [2] >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__releases.llvm.org_9.0.0_llvm-2D9.0.0.src.tar.xz&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=se8pV6OlDAeF2g5iEAvSB2qhLBJGPaHADv3NQVNFx6U&s=IzBxNhAvcILfAD_XcSB7t0s6-B-wFY3TBoVGH6WhRK8&e= >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__releases.llvm.org_9.0.0_clang-2Dtools-2Dextra-2D9.0.0.src.tar.xz&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=se8pV6OlDAeF2g5iEAvSB2qhLBJGPaHADv3NQVNFx6U&s=KkjCjWm_q2iMfFh50rTKtFqQEMbRBVhT9Oh8KMfgwW4&e= >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__releases.llvm.org_9.0.0_cfe-2D9.0.0.src.tar.xz&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=se8pV6OlDAeF2g5iEAvSB2qhLBJGPaHADv3NQVNFx6U&s=TvkN9sb5rSB5BNxJP27UmCsfNHsRQdaVeAnBa1TkyjM&e= >>>> >>>> Now, i am trying with llc -march=bpf, with this segmentation fault is >>>> coming as below: >>>> >>>> gcc -g -Wall -O2 -I../../../include/uapi -I../../../lib >>>> -I../../../lib/bpf -I../../../../include/generated -DHAVE_GENHDR >>>> -I../../../include -Dbpf_prog_load=bpf_prog_test_load >>>> -Dbpf_load_program=bpf_test_load_program test_flow_dissector.c >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_stub.o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/libbpf.a -lcap -lelf >>>> -lrt -lpthread -o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_flow_dissector >>>> gcc -g -Wall -O2 -I../../../include/uapi -I../../../lib >>>> -I../../../lib/bpf -I../../../../include/generated -DHAVE_GENHDR >>>> -I../../../include -Dbpf_prog_load=bpf_prog_test_load >>>> -Dbpf_load_program=bpf_test_load_program >>>> test_tcp_check_syncookie_user.c >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_stub.o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/libbpf.a -lcap -lelf >>>> -lrt -lpthread -o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_tcp_check_syncookie_user >>>> gcc -g -Wall -O2 -I../../../include/uapi -I../../../lib >>>> -I../../../lib/bpf -I../../../../include/generated -DHAVE_GENHDR >>>> -I../../../include -Dbpf_prog_load=bpf_prog_test_load >>>> -Dbpf_load_program=bpf_test_load_program test_lirc_mode2_user.c >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_stub.o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/libbpf.a -lcap -lelf >>>> -lrt -lpthread -o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_lirc_mode2_user >>>> (clang -I. -I./include/uapi -I../../../include/uapi >>>> -I/usr/src/tovards/linux/tools/testing/selftests/bpf/../usr/include >>>> -D__TARGET_ARCH_arm64 -g -idirafter /usr/local/include -idirafter >>>> /usr/local/lib/clang/9.0.0/include -idirafter >>>> /usr/include/aarch64-linux-gnu -idirafter /usr/include >>>> -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm \ >>>> -c progs/test_core_reloc_arrays.c -o - || echo "clang failed") | \ >>>> llc -march=bpf -mcpu=probe -filetype=obj -o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_arrays.o >>>> Stack dump: >>>> 0. Program arguments: llc -march=bpf -mcpu=probe -filetype=obj -o >>>> /usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_arrays.o >>>> 1. Running pass 'Function Pass Manager' on module '<stdin>'. >>>> 2. Running pass 'BPF Assembly Printer' on function '@test_core_arrays' >>>> #0 0x0000aaaac618db08 llvm::sys::PrintStackTrace(llvm::raw_ostream&) >>>> (/usr/local/bin/llc+0x152eb08) >>>> Segmentation fault >>> >>> Hi, >>> >>> FWIW I can confirm that this is happening on s390 too with llvm-project >>> commit 950b800c451f. >>> >>> Here is the reduced sample that triggers this (with -march=bpf >>> -mattr=+alu32): >>> >>> struct b { >>> int e; >>> } c; >>> int f() { >>> return __builtin_preserve_field_info(c.e, 0); >>> } >>> >>> This is compiled into: >>> >>> 0B bb.0 (%ir-block.0): >>> 16B %0:gpr = LD_imm64 @"b:0:0$0:0" >>> 32B $w0 = COPY %0:gpr, debug-location !17; 1-E.c:5:3 >>> 48B RET implicit killed $w0, debug-location !17; 1-E.c:5:3 >>> >>> and then BPFInstrInfo::copyPhysReg chokes on COPY, since $w0 and %0 are >>> in different register classes. >> >> Ilya, >> >> Thanks for reporting. I can reproduce the issue with latest trunk. >> I will investigate and fix the problem soon. >> >> Yonghong > > Thanks for taking care of this! Just FYI, bisect pointed to 05e46979d2f4 > ("[BPF] do compile-once run-everywhere relocation for bitfields"). > > Could you please add me to Phabricator review? I'm curious what the I did add you in the diff https://reviews.llvm.org/D69438. > proper solution is going to be, as I'm still not sure whether handling > asymmetric copies is the right approach, or whether they should rather > be prevented from occuring in the first place. The change has been pushed into the trunk. We indeed used asymmetric copy. Please do let me know if you think there is a better way to do that. Thanks! > > Best regards, > Ilya >
