From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F46DC433E0 for ; Tue, 19 Jan 2021 23:20:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4456A22DD3 for ; Tue, 19 Jan 2021 23:20:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727272AbhASXU2 (ORCPT ); Tue, 19 Jan 2021 18:20:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23749 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729209AbhASXTA (ORCPT ); Tue, 19 Jan 2021 18:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611098251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=X2pcChHGftd9Kzu4vux4bBucIycf/Pi8Nee8dh6Osj0=; b=NsCF0yk8VqnLeH6rhiMLzPRbvpr3ynMgM8Lg5EYDJCQrcjWRZRnxi5JZom/TPQ3ESOtG4D RBxAoWoql6sphCmP4NgGQIQC8YXz+t0Q0qmCllSwAyNgvV2WEbr3mBqGvuK53bssLqL5rL 0aYNBxd+uAFCz63LLYINxj5urQttx4w= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-319-AvmReq3dM-mztp_ixXzDhw-1; Tue, 19 Jan 2021 18:17:30 -0500 X-MC-Unique: AvmReq3dM-mztp_ixXzDhw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 067ED15720; Tue, 19 Jan 2021 23:17:28 +0000 (UTC) Received: from redhat.com (ovpn-112-133.rdu2.redhat.com [10.10.112.133]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 978266268F; Tue, 19 Jan 2021 23:17:20 +0000 (UTC) Date: Tue, 19 Jan 2021 18:17:18 -0500 From: Joe Lawrence To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , dwarves@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Yonghong Song , Hao Luo , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Mark Wielaard Subject: Re: [PATCH 0/3] dwarves,libbpf: Add support to use optional extended section index table Message-ID: <20210119231718.GA3173@redhat.com> References: <20210119221220.1745061-1-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210119221220.1745061-1-jolsa@kernel.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Jan 19, 2021 at 11:12:17PM +0100, Jiri Olsa wrote: > hi, > kpatch guys hit an issue with pahole over their vmlinux, which > contains many (over 100000) sections, pahole crashes. > FWIW this is probably only going to be problem when building the kernel with -f[function|data]-sections and tipping over 65536 sections. We only use these option to determine code deltas, but other users (FG-ASLR, LTO?) may need to actually build runtime code. > With so many sections, ELF is using extended section index table, > which is used to hold values for some of the indexes and extra > code is needed to retrieve them. > > This patchset adds the support for pahole to properly read string > table index and symbol's section index, which are used in btf_encoder. > > This patchset also adds support for libbpf to properly parse .BTF > section on such object. > > This patchset based on previously posted fix [1]. > Hi Jiri, Thanks for posting a potential fix, here's what I saw when running it: 1-Installed your scratch build: % rpm -q --whatprovides $(which pahole) dwarves-1.19-2.el8.x86_64 2-From the kernel build: LD vmlinux.o MODPOST vmlinux.o BTF .btf.vmlinux.bin.o scripts/link-vmlinux.sh: line 127: 1851330 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} objcopy: --change-section-vma .BTF=0x0000000000000000 never used objcopy: --change-section-lma .BTF=0x0000000000000000 never used objcopy: error: the input file '.btf.vmlinux.bin' is empty Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make: *** [Makefile:1050: vmlinux] Error 1 3-coredump backtrace: ... Core was generated by `pahole -J .tmp_vmlinux.btf'. ... (gdb) bt #0 0x00007fc0e81e31c0 in __memcpy_ssse3 () from /lib64/libc.so.6 #1 0x00007fc0e8b6700a in memcpy (__len=306248, __src=, __dest=0x7fc0e91a0010) at /usr/include/bits/string_fortified.h:34 #2 get_vmlinux_addrs (btfe=, pcount=, paddrs=, fl=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/btf_encoder.c:167 #3 setup_functions (fl=, btfe=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/btf_encoder.c:251 #4 collect_symbols (collect_percpu_vars=, btfe=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/btf_encoder.c:645 #5 cu__encode_btf (cu=, verbose=0, force=false, skip_encoding_vars=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/btf_encoder.c:694 #6 0x000055eb2e4b6cc5 in pahole_stealer (cu=0x55eb2ecbb920, conf_load=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/pahole.c:2402 #7 0x00007fc0e8b6d2db in finalize_cu_immediately (conf=0x55eb2e6bc0e0 , dcu=0x7ffd88fda9d0, cu=0x55eb2ecbb920, cus=0x55eb2ecbb5d0) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarf_loader.c:2477 #8 cus__load_module (cus=cus@entry=0x55eb2ecbb5d0, conf=0x55eb2e6bc0e0 , mod=mod@entry=0x55eb2ecbb5f0, dw=0x55eb2ecbe6a0, elf=elf@entry=0x7fc0ad941010, filename=0x7ffd8905b98d ".tmp_vmlinux.btf") at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarf_loader.c:2477 #9 0x00007fc0e8b6d5c5 in cus__process_dwflmod (dwflmod=0x55eb2ecbb5f0, userdata=, name=, base=, arg=0x7ffd8905ab00) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarf_loader.c:2522 #10 0x00007fc0e88f9c71 in dwfl_getmodules () from /lib64/libdw.so.1 #11 0x00007fc0e8b69cdc in cus__process_file (filename=, fd=5, conf=0x55eb2e6bc0e0 , cus=0x55eb2ecbb5d0) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarf_loader.c:2575 #12 dwarf__load_file (cus=0x55eb2ecbb5d0, conf=0x55eb2e6bc0e0 , filename=) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarf_loader.c:2592 #13 0x00007fc0e8b5cb82 in cus__load_file (cus=cus@entry=0x55eb2ecbb5d0, conf=conf@entry=0x55eb2e6bc0e0 , filename=0x7ffd8905b98d ".tmp_vmlinux.btf") at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarves.c:1963 #14 0x00007fc0e8b5ce29 in cus__load_files (cus=0x55eb2ecbb5d0, conf=0x55eb2e6bc0e0 , filenames=0x7ffd8905aea8) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/dwarves.c:2324 #15 0x000055eb2e4b371e in main (argc=3, argv=0x7ffd8905ae98) at /usr/src/debug/dwarves-1.19-2.el8.x86_64/pahole.c:2760 I uploaded a gzipped core file here: http://people.redhat.com/~jolawren/coredump.gz If it's easier to get you setup on a repro system, let me know and I can do that. Thanks, -- Joe