Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4595160pxu; Tue, 20 Oct 2020 23:43:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBOA1jyakysbWSMl9/ungJt0JP46oYv1CD7Gd7KTgYPRzwwJnCOkEfjzZZzPtJVZ8UEZha X-Received: by 2002:a50:cc0c:: with SMTP id m12mr1533780edi.292.1603262618705; Tue, 20 Oct 2020 23:43:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603262618; cv=none; d=google.com; s=arc-20160816; b=hsHQojeW8Qgsx3xto2bgy4pDV99wamt0jGTR2ocXXl/2fgfZ+jJ0qndHNqjsT6y/Mp LNTT1BMgPQpoz0DwofcbvJr24VmrFC8U8Fk5DQ3xRNbTL908dWUcainUilNWAIbrt5ha czK98/6D/D9cL1PXw11v4faTR2M/0UoPran7QGr9cXIBJCH63QaNYmi6yayNG4LufkTF 1Js4TwN7AecPgBchRhZBamOfqBI1eZQ6CQEoKeR2L+b1w/GTOcJtK5gX7D3hJhrhKsSV IllEf2HSKmppuc/ny83AnYOeXdiEbfYG4woeGU4ecdsnApyQvqF47lMVQ/1EKQM3WRKj ofKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=C3MYOAyER7eRaYplTmQSfHj/vWn2iuqLFvr+uBlCcqo=; b=DICQAmeV/GOtoFj8oLZqTlW38/kf8STpf4wEAhayv+J5ySTP6kLNtrCKBMx9ceXPEJ 0wRlu2BaY/OHps3m4hNeLBYhw6gNSfqNeiGp+Ur/M/y0U61NSKQHysD+XEi1eJ0hfXSE v7Vo0zVxKmjSq1dDXy2ARPPSQTIycE+0ojA6oxf+//2HnUgvixiPVBg9RObIDuFHziZ8 cerfoaUKF6iypipF2SKCGZR0HUDTwYai5YMfatnU3Xj0CyFec3jdO76EMl+Bbg5xD/SN yVaxltel+K/V5rLMx6he+JFx556HZbGQMVHlJ/gqtClViE/pGkKnZkifLEsn3g/1InDc tcPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="V/PAKYc4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qq26si711683ejb.103.2020.10.20.23.43.16; Tue, 20 Oct 2020 23:43:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="V/PAKYc4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395126AbgJTRFE (ORCPT + 99 others); Tue, 20 Oct 2020 13:05:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395094AbgJTRFE (ORCPT ); Tue, 20 Oct 2020 13:05:04 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9984AC0613D3 for ; Tue, 20 Oct 2020 10:05:03 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id lw21so3824458ejb.6 for ; Tue, 20 Oct 2020 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C3MYOAyER7eRaYplTmQSfHj/vWn2iuqLFvr+uBlCcqo=; b=V/PAKYc4GxLuXpfbfMJ0VbWKyR+7WMwU1gnH/2YMxkbSDus2F5e2kUtOPOxVoC8ZT8 9opgnVcA6VPuNqboTwrxIqtb5hjkW48s8OtJ/zJ8t+NRCaa5LQM9yC5ONYmtVU3Q6GUU mUvklSgRgWxehghpVoRtCUSbLLAk/9e3gxvbiH5DVnaHE4OxUZyeQd2/i+x2d6gwMNM+ mh3ZvufUXbZyG9uA8NR096OFziC3Fpj3ssV+svvNfvLNiybSLx7RV7wcnOnwtbbnUtiI 4addjtvIv6hf+ooUbEpB6GD/qhE1nyN6d4TqRjxQp/zE4WZPCwAMncWphqcYGYhZDtuO Nvyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C3MYOAyER7eRaYplTmQSfHj/vWn2iuqLFvr+uBlCcqo=; b=sIOrR8fxAjtcCkkX5eThNsUdmmhTc/4v/G9HhrUhbUohNgAAaXNO1sg9hfvl0V2KEC iEzhpA2vLm/FS8cOIIOwZCX2H6qh94SNOOetDBFWnvf2p1nimh+dlDNVzYdEY8Yv/u7S SKWyOvqZF/gJPKMYAKjdqKLrUYwUx6yhzPYAAjPsuHiWR/5FRRNCOaboH3tm8zW0iHGZ 2w9xA5DEdetsQH3HF5K1jmvwixJ2oiUvOKmYkhc3jrO3EYNMjo8xCqUkKKIOJP9xtW+K x23NT6byC4AFxT8wyzD1OPRS2jljbKWmkbDvQi8xGTYKkbjZ9Rt1IL7mqB4egbLmpFtX +qDQ== X-Gm-Message-State: AOAM531Ww1G66J4EbqVlgtwZmaCEwICofzx3rEMrx69JurzZn0IOmUsq 45WY8Ykc0sjP6jDvrzcTrRm1QTAPBxJQH44FpsarBg== X-Received: by 2002:a17:906:4e19:: with SMTP id z25mr4369995eju.44.1603213501911; Tue, 20 Oct 2020 10:05:01 -0700 (PDT) MIME-Version: 1.0 References: <82b757bb-1f49-ab02-2f4b-89577d56fec9@kernel.org> <20201020122015.GH2294271@kernel.org> In-Reply-To: <20201020122015.GH2294271@kernel.org> From: Hao Luo Date: Tue, 20 Oct 2020 10:04:50 -0700 Message-ID: Subject: Re: Segfault in pahole 1.18 when building kernel 5.9.1 for arm64 To: Arnaldo Carvalho de Melo Cc: Jiri Slaby , =?UTF-8?B?w4lyaWNvIFJvbGlt?= , dwarves@vger.kernel.org, open list , Arnaldo Carvalho de Melo , Andrii Nakryiko , Alexei Starovoitov , bpf , Andrii Nakryiko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for reporting this and cc'ing me. I forgot to update the error messages when renaming the flags. I will send a patch to fix the error message. The commit commit f3d9054ba8ff1df0fc44e507e3a01c0964cabd42 Author: Hao Luo AuthorDate: Wed Jul 8 13:44:10 2020 -0700 btf_encoder: Teach pahole to store percpu variables in vmlinux BTF. encodes kernel global variables into BTF so that bpf programs can directly access them. If there is no need to access kernel global variables, it's perfectly fine to use '--btf_encode_force' to skip encoding bad symbols into BTF, or '--skip_encoding_btf_vars' to skip encoding all global vars all together. I will add these info into the updated error message. Also cc bpf folks for attention of this bug. Hao On Tue, Oct 20, 2020 at 5:20 AM Arnaldo Carvalho de Melo wrote: > > Em Tue, Oct 20, 2020 at 11:01:39AM +0200, Jiri Slaby escreveu: > > Hi, > > > > On 19. 10. 20, 1:18, =C3=89rico Rolim wrote: > > > I'm trying to build kernel 5.9.1 for arm64, and my dotconfig has > > > `CONFIG_DEBUG_INFO_BTF=3Dy`, which requires pahole for building. Howe= ver, pahole > > > version 1.18 segfaults during the build, as can be seen below: > > > > > > PAHOLE: Error: Found symbol of zero size when encoding btf (sym: > > > '__kvm_nvhe_arm64_ssbd_callback_required', cu: > > > 'arch/arm64/kernel/cpu_errata.c'). > > > > The symbol is an alias coming from arch/arm64/kernel/vmlinux.lds: > > __kvm_nvhe_arm64_ssbd_callback_required =3D arm64_ssbd_callback_require= d;; > > > > > PAHOLE: Error: Use '-j' or '--force' to ignore such symbols and force > > > emit the btf. > > > scripts/link-vmlinux.sh: line 141: 43837 Segmentation fault > > > LLVM_OBJCOPY=3D${OBJCOPY} ${PAHOLE} -J ${1} > > > LD .tmp_vmlinux.kallsyms1 > > > KSYM .tmp_vmlinux.kallsyms1.o > > > LD .tmp_vmlinux.kallsyms2 > > > KSYM .tmp_vmlinux.kallsyms2.o > > > LD vmlinux > > > BTFIDS vmlinux > > > FAILED: load BTF from vmlinux: Unknown error -2make: *** > > > [Makefile:1162: vmlinux] Error 255 > > > > > > It is possible to force the build to continue if > > > > > > LLVM_OBJCOPY=3D${OBJCOPY} ${PAHOLE} -J ${1} > > > > > > in scripts/link-vmlinux.sh is changed to > > > > > > LLVM_OBJCOPY=3D${OBJCOPY} ${PAHOLE} -J --btf_encode_force ${1} > > > > > > The suggested `-j` or `--force` flags don't exist, since they were re= moved in > > > [1]. I believe `--btf_encode_force` should be suggested instead. > > > > Agreed, '--btf_encode_force' makes pahole to proceed without crashes. > > > > > It should be noted that the same build, but with pahole version 1.17,= works > > > without issue, so I think this is either a regression in pahole or th= e script > > > will need to be changed for newer versions of pahole. > > > > Yeah, I observe the very same. I reported it at: > > https://bugzilla.suse.com/show_bug.cgi?id=3D1177921 > > Would it be possible to try with > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=3Dtmp.li= bbtf_encoder > ? > > This switches to using libbpf for the BTF encoder and may have fixed > this problem. > > - Arnaldo > > > The backtrace: > > > (gdb) where > > > #0 __memmove_sse2_unaligned_erms () at > > ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:300 > > > #1 0x00007ffff7f78346 in memcpy (__len=3D, __src=3D > out>, __dest=3D, __dest=3D, __src=3D, > > __len=3D) at /usr/include/bits/string_fortified.h:34 > > > #2 gobuffer__add (gb=3D0x555555569aa0, s=3D0x7fffffffb50c, len=3D12)= at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/gobuffer.c:87 > > > #3 0x00007ffff7f8671f in btf_elf__add_datasec_type > > (btfe=3Dbtfe@entry=3D0x555555569a40, > > section_name=3Dsection_name@entry=3D0x7ffff7fa43ad ".data..percpu", > > var_secinfo_buf=3Dvar_secinfo_buf@entry=3D0x555555569ac0) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/libbtf.c:721 > > > #4 0x00007ffff7f8d766 in btf_elf__encode (flags=3D0 '\000', > > btfe=3D0x555555569a40) at /usr/src/debug/dwarves-1.18-1.1.x86_64/libbtf= .c:857 > > > #5 btf_elf__encode (btfe=3D0x555555569a40, flags=3D) = at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/libbtf.h:71 > > > #6 0x00007ffff7f7fc70 in btf_encoder__encode () at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/btf_encoder.c:213 > > > #7 0x00007ffff7f80d17 in cu__encode_btf (cu=3D0x55555638d9b0, verbos= e=3D0, > > force=3Dfalse, skip_encoding_vars=3Dfalse) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/btf_encoder.c:255 > > > #8 0x000055555555ac4d in pahole_stealer (cu=3D0x55555638d9b0, > > conf_load=3D) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/pahole.c:2366 > > > #9 0x00007ffff7f89dab in finalize_cu (cus=3D0x5555555622d0, > > dcu=3D0x7fffffffd080, conf=3D0x5555555610e0 , cu=3D0x5555563= 8d9b0) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2473 > > > #10 finalize_cu_immediately (conf=3D0x5555555610e0 , > > dcu=3D0x7fffffffd080, cu=3D0x55555638d9b0, cus=3D0x5555555622d0) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2317 > > > #11 cus__load_module (cus=3Dcus@entry=3D0x5555555622d0, conf=3D0x5555= 555610e0 > > , mod=3Dmod@entry=3D0x555555564760, dw=3D0x555555565960, > > elf=3Delf@entry=3D0x555555562360, filename=3D0x7fffffffe846 "ss") at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2473 > > > #12 0x00007ffff7f8a0f1 in cus__process_dwflmod (dwflmod=3D0x555555564= 760, > > userdata=3D, name=3D, base=3D, > > arg=3D0x7fffffffe1b0) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2518 > > > #13 0x00007ffff7d4f571 in dwfl_getmodules () from /usr/lib64/libdw.so= .1 > > > #14 0x00007ffff7f823ed in cus__process_file (filename=3D0x7fffffffe84= 6 "ss", > > fd=3D3, conf=3D, cus=3D0x5555555622d0) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2571 > > > #15 dwarf__load_file (cus=3D0x5555555622d0, conf=3D, > > filename=3D0x7fffffffe846 "ss") at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarf_loader.c:2588 > > > #16 0x00007ffff7f76771 in cus__load_file (cus=3Dcus@entry=3D0x5555555= 622d0, > > conf=3Dconf@entry=3D0x5555555610e0 , filename=3D0x7fffffffe8= 46 "ss") at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarves.c:1958 > > > #17 0x00007ffff7f798a8 in cus__load_files (cus=3D0x5555555622d0, > > conf=3D0x5555555610e0 , filenames=3D0x7fffffffe518) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/dwarves.c:2316 > > > #18 0x00005555555576fc in main (argc=3D3, argv=3D0x7fffffffe508) at > > /usr/src/debug/dwarves-1.18-1.1.x86_64/pahole.c:2687 > > > > > > I suspect: > > commit f3d9054ba8ff1df0fc44e507e3a01c0964cabd42 > > Author: Hao Luo > > AuthorDate: Wed Jul 8 13:44:10 2020 -0700 > > > > btf_encoder: Teach pahole to store percpu variables in vmlinux BTF. > > > > > > Which added this machinery (btf_elf__add_datasec_type in particular). > > > > > - [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/p= ahole.c?h=3Dv1.18&id=3D1abc001417b579b86a9b27ff88c9095d8f498a46 > > > > > > Thanks, > > > =C3=89rico > > > > > > > > > -- > > js > > suse labs > > -- > > - Arnaldo