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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 5C2EDC433DB for ; Tue, 12 Jan 2021 16:23:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C41D22B2B for ; Tue, 12 Jan 2021 16:23:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406828AbhALQXh (ORCPT ); Tue, 12 Jan 2021 11:23:37 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:32448 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406736AbhALQXe (ORCPT ); Tue, 12 Jan 2021 11:23:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610468527; 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=cYzIRpyRb+wLWcBSyowl7QWEaoL4nInBFatkgQBtBh4=; b=OxVhvA1ERDnmKDAHuGFldQWcj6b1QBlUABOd2n4idCqEtq6HKl1WuBsJE7e2WJynY5S55a pOMa7P1t/mRK+D403vab0onMpEby93OjzZ258XMJbeppJ/+lEMRyIz3J8xRc/5IP60ebz2 XRKYxV2eFPwMboskM17A4NQbaPf/W10= 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-174-DSa7YmmMM0yqM22Ktn6n7g-1; Tue, 12 Jan 2021 11:22:03 -0500 X-MC-Unique: DSa7YmmMM0yqM22Ktn6n7g-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2B2F7180A0A6; Tue, 12 Jan 2021 16:22:00 +0000 (UTC) Received: from krava (unknown [10.40.194.156]) by smtp.corp.redhat.com (Postfix) with SMTP id 166C31975F; Tue, 12 Jan 2021 16:21:56 +0000 (UTC) Date: Tue, 12 Jan 2021 17:21:56 +0100 From: Jiri Olsa To: Sedat Dilek Cc: Tom Stellard , Andrii Nakryiko , Jiri Olsa , Yonghong Song , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Masahiro Yamada , bpf , Linux Kbuild mailing list Subject: Re: Check pahole availibity and BPF support of toolchain before starting a Linux kernel build Message-ID: <20210112162156.GA1291051@krava> References: <20210111223144.GA1250730@krava> <20210112104622.GA1283572@krava> <20210112131012.GA1286331@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Jan 12, 2021 at 05:14:42PM +0100, Sedat Dilek wrote: > On Tue, Jan 12, 2021 at 2:10 PM Jiri Olsa wrote: > > > > On Tue, Jan 12, 2021 at 11:46:22AM +0100, Jiri Olsa wrote: > > > On Mon, Jan 11, 2021 at 02:34:04PM -0800, Tom Stellard wrote: > > > > On 1/11/21 2:31 PM, Jiri Olsa wrote: > > > > > On Mon, Jan 11, 2021 at 10:30:22PM +0100, Sedat Dilek wrote: > > > > > > > > > > SNIP > > > > > > > > > > > > > > > > > > > > > Building a new Linux-kernel... > > > > > > > > > > > > > > > > - Sedat - > > > > > > > > > > > > > > > > [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ > > > > > > > > [2] https://github.com/ClangBuiltLinux/tc-build/issues/129#issuecomment-758026878 > > > > > > > > [3] https://github.com/ClangBuiltLinux/tc-build/issues/129#issuecomment-758056553 > > > > > > > > > > > > > > There are no significant bug fixes between pahole 1.19 and master that > > > > > > > would solve this problem, so let's try to repro this. > > > > > > > > > > > > > > > > > > > You are right pahole fom latest Git does not solve the issue. > > > > > > > > > > > > + info BTFIDS vmlinux > > > > > > + [ != silent_ ] > > > > > > + printf %-7s %s\n BTFIDS vmlinux > > > > > > BTFIDS vmlinux > > > > > > + ./tools/bpf/resolve_btfids/resolve_btfids vmlinux > > > > > > FAILED: load BTF from vmlinux: Invalid argument > > > > > > > > > > hm, is there a .BTF section in vmlinux? > > > > > > > > > > is this working over vmlinux: > > > > > $ bpftool btf dump file ./vmlinux > > > > > > > > > > do you have a verbose build output? I'd think pahole scream first.. > > > > > > > > > > > > > It does. For me, pahole segfaults at scripts/link-vmlinux.sh:131. This is > > > > pretty easy for me to reproduce. I have logs, what other information would > > > > be helpful? How about a pahole backtrace? > > > > > > that'd be great.. I'll try to reproduce, but with the latest clang > > > it will take me some time > > > > reproduced, attached pahole patch fixes it for me, > > > > looks like gcc never left function without name, > > which does not seem to be the case for clang > > > > I'll send full patch later today > > > > Thanks for the diff. > > Unfortunately, it does not apply on latest pahole git. > > $ git describe > v1.19-7-gb688e3597060 sry wrong master.. how about this one jirka --- diff --git a/btf_encoder.c b/btf_encoder.c index 333973054b61..17f7a14f2ef0 100644 --- a/btf_encoder.c +++ b/btf_encoder.c @@ -72,6 +72,8 @@ static int collect_function(struct btf_elf *btfe, GElf_Sym *sym) if (elf_sym__type(sym) != STT_FUNC) return 0; + if (!elf_sym__name(sym, btfe->symtab)) + return 0; if (functions_cnt == functions_alloc) { functions_alloc = max(1000, functions_alloc * 3 / 2); @@ -730,9 +732,11 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force, if (!has_arg_names(cu, &fn->proto)) continue; if (functions_cnt) { - struct elf_function *func; + const char *name = function__name(fn, cu); + struct elf_function *func = NULL; - func = find_function(btfe, function__name(fn, cu)); + if (name) + func = find_function(btfe, name); if (!func || func->generated) continue; func->generated = true; -- 2.26.2