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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0F608C433E0 for ; Wed, 24 Jun 2020 18:57:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E937B2084D for ; Wed, 24 Jun 2020 18:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593025061; bh=0vtM4n//w3r25+ntM4pHDDHI/ay33GW0wTi9fulQgmU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ekQLmGl1ZWEVV40WJcn2f6FlCO7HvKxbR7Pp+jkiyZUUSTO//bDaGUBDz9l4GcXk8 +5Q3p8REbWkIzw2/YNjyOUjqs/hUCdMmCFg1hTI+aER+fmocAtQqDJCoMJzEfOren4 VDeB3P6eZwDsN5vSZnL5IBFdIamOFcRY+tXGBTXQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406077AbgFXS5k (ORCPT ); Wed, 24 Jun 2020 14:57:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51158 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405469AbgFXS5k (ORCPT ); Wed, 24 Jun 2020 14:57:40 -0400 Received: from quaco.ghostprotocols.net (unknown [179.97.37.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2DCA72082F; Wed, 24 Jun 2020 18:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593025059; bh=0vtM4n//w3r25+ntM4pHDDHI/ay33GW0wTi9fulQgmU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vsJSnIkaB03iZxTqbqOOohd16f/ljhMAkmoUZ0LnQAWDHMApP7mrRcGyFZz7a/Ipv SBM/etdu5rgerDwZya0ZxLA2KE1Wl251FvNaeCtDN7/JiR9/B9EevmT3Iz9jFMP51r UxoSH8yVeGMwztKTdW1lNPDjU6InWIv2/wnvJrs0= Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 53B51405FF; Wed, 24 Jun 2020 15:57:37 -0300 (-03) Date: Wed, 24 Jun 2020 15:57:37 -0300 From: Arnaldo Carvalho de Melo To: Andrii Nakryiko Cc: Arnaldo Carvalho de Melo , Lorenz Bauer , bpf , dwarves@vger.kernel.org, kernel-team Subject: Re: pahole generates invalid BTF for code compiled with recent clang Message-ID: <20200624185737.GA25807@kernel.org> References: <20200624175754.GD20203@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Em Wed, Jun 24, 2020 at 11:40:21AM -0700, Andrii Nakryiko escreveu: > On Wed, Jun 24, 2020 at 10:57 AM Arnaldo Carvalho de Melo > wrote: > > > > Em Wed, Jun 24, 2020 at 10:41:10AM -0700, Andrii Nakryiko escreveu: > > > On Wed, Jun 24, 2020 at 4:07 AM Lorenz Bauer wrote: > > > > > > > > Hi, > > > > > > > > If pahole -J is used on an ELF that has BTF info from clang, it > > > > produces an invalid > > > > output. This is because pahole rewrites the .BTF section (which > > > > includes a new string > > > > table) but it doesn't touch .BTF.ext at all. > > > > > > Why do you run `pahole -J` on BPF .o file? Clang already generates > > > .BTF (and .BTF.ext, of course) for you. > > > > > > pahole -J is supposed to be used for vmlinux, not for clang-compiled > > > -target BPF object files. > > > > yeah, I was thinking this was for a vmlinux generated by clang, which, > > from the commands below (the suffix _prog.o) should have told me this is > > a target BPF object file. > > > > But then, if one insists for some reason in generating BTF from the > > DWARF in a BPF target object file, stripping .BTF.ext, if present, is > > the right thing to do at this point. > > I disagree. Those who insist probably have some wrong conceptual > understanding and it's better to fix that (understanding), rather than > lose focus and bend tool to do what it's not supposed to do and > ultimately cause more confusion. So we can instead notice the presence of .BTF.ext when the user calls 'pahole -J' on a target BPF object file and bail out, only allowing it to convert from DWARF to BTF and thus encode the .BTF elf section when .BTF.ext isn't present, as we can't easily figure out if the present of just .BTF section was done by clang or pahole on a BTF target object file built without -g. - Arnaldo > pahole's BTF conversion is really driven towards kernel use-case > (e.g., with global variables, etc). I wouldn't distract ourselves with > supporting de-duplicating BPF object files. Single .o's BTF is already > deduplicated as produced by Clang. Once we add static linking of > multiple BPF .o's (which I hope to start working on very soon), that > de-duplication will be handled automatically by libbpf (and hopefully > integrated into lld as well), among many other things that need to > happen to make static linking work. > > > > > - Arnaldo > > > > > > > > > > To demonstrate, on a recent check out of bpf-next: > > > > $ cp connect4_prog.o connect4_pahole.o > > > > $ pahole -J connect4_pahole.o > > > > $ llvm-objcopy-10 --dump-section .BTF=pahole-btf.bin > > > > --dump-section .BTF.ext=pahole-btf-ext.bin connect4_pahole.o > > > > $ llvm-objcopy-10 --dump-section .BTF=btf.bin --dump-section > > > > .BTF.ext=btf-ext.bin connect4_prog.o > > > > $ sha1sum *.bin > > > > 1b5c7407dd9fd13f969931d32f6b864849e66a68 btf.bin > > > > 4c43efcc86d3cd908ddc77c15fc4a35af38d842b btf-ext.bin > > > > 2a60767a3a037de66a8d963110601769fa0f198e pahole-btf.bin > > > > 4c43efcc86d3cd908ddc77c15fc4a35af38d842b pahole-btf-ext.bin > > > > > > > > This problem crops up when compiling old kernels like 4.19 which have > > > > an extra pahole > > > > build step with clang-10. > > > > > > I was under impression that clang generates .BTF and .BTF.ext only for > > > -target BPF. In this case, kernel is compiled for "real" target arch, > > > so there shouldn't be .BTF.ext in the first place? If that's not the > > > case, then I guess it's a bug in Clang. > > > > > > > > > > > I think a possible fix is to strip .BTF.ext if .BTF is rewritten. > > > > > > > > Best > > > > Lorenz > > > > > > > > -- > > > > Lorenz Bauer | Systems Engineer > > > > 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK > > > > > > > > www.cloudflare.com > > > > -- > > > > - Arnaldo -- - Arnaldo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnaldo Carvalho de Melo Subject: Re: pahole generates invalid BTF for code compiled with recent clang Date: Wed, 24 Jun 2020 15:57:37 -0300 Message-ID: <20200624185737.GA25807@kernel.org> References: <20200624175754.GD20203@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: dwarves-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andrii Nakryiko Cc: Arnaldo Carvalho de Melo , Lorenz Bauer , bpf , dwarves-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-team List-Id: dwarves@vger.kernel.org Em Wed, Jun 24, 2020 at 11:40:21AM -0700, Andrii Nakryiko escreveu: > On Wed, Jun 24, 2020 at 10:57 AM Arnaldo Carvalho de Melo > wrote: > > > > Em Wed, Jun 24, 2020 at 10:41:10AM -0700, Andrii Nakryiko escreveu: > > > On Wed, Jun 24, 2020 at 4:07 AM Lorenz Bauer wrote: > > > > > > > > Hi, > > > > > > > > If pahole -J is used on an ELF that has BTF info from clang, it > > > > produces an invalid > > > > output. This is because pahole rewrites the .BTF section (which > > > > includes a new string > > > > table) but it doesn't touch .BTF.ext at all. > > > > > > Why do you run `pahole -J` on BPF .o file? Clang already generates > > > .BTF (and .BTF.ext, of course) for you. > > > > > > pahole -J is supposed to be used for vmlinux, not for clang-compiled > > > -target BPF object files. > > > > yeah, I was thinking this was for a vmlinux generated by clang, which, > > from the commands below (the suffix _prog.o) should have told me this is > > a target BPF object file. > > > > But then, if one insists for some reason in generating BTF from the > > DWARF in a BPF target object file, stripping .BTF.ext, if present, is > > the right thing to do at this point. > > I disagree. Those who insist probably have some wrong conceptual > understanding and it's better to fix that (understanding), rather than > lose focus and bend tool to do what it's not supposed to do and > ultimately cause more confusion. So we can instead notice the presence of .BTF.ext when the user calls 'pahole -J' on a target BPF object file and bail out, only allowing it to convert from DWARF to BTF and thus encode the .BTF elf section when .BTF.ext isn't present, as we can't easily figure out if the present of just .BTF section was done by clang or pahole on a BTF target object file built without -g. - Arnaldo > pahole's BTF conversion is really driven towards kernel use-case > (e.g., with global variables, etc). I wouldn't distract ourselves with > supporting de-duplicating BPF object files. Single .o's BTF is already > deduplicated as produced by Clang. Once we add static linking of > multiple BPF .o's (which I hope to start working on very soon), that > de-duplication will be handled automatically by libbpf (and hopefully > integrated into lld as well), among many other things that need to > happen to make static linking work. > > > > > - Arnaldo > > > > > > > > > > To demonstrate, on a recent check out of bpf-next: > > > > $ cp connect4_prog.o connect4_pahole.o > > > > $ pahole -J connect4_pahole.o > > > > $ llvm-objcopy-10 --dump-section .BTF=pahole-btf.bin > > > > --dump-section .BTF.ext=pahole-btf-ext.bin connect4_pahole.o > > > > $ llvm-objcopy-10 --dump-section .BTF=btf.bin --dump-section > > > > .BTF.ext=btf-ext.bin connect4_prog.o > > > > $ sha1sum *.bin > > > > 1b5c7407dd9fd13f969931d32f6b864849e66a68 btf.bin > > > > 4c43efcc86d3cd908ddc77c15fc4a35af38d842b btf-ext.bin > > > > 2a60767a3a037de66a8d963110601769fa0f198e pahole-btf.bin > > > > 4c43efcc86d3cd908ddc77c15fc4a35af38d842b pahole-btf-ext.bin > > > > > > > > This problem crops up when compiling old kernels like 4.19 which have > > > > an extra pahole > > > > build step with clang-10. > > > > > > I was under impression that clang generates .BTF and .BTF.ext only for > > > -target BPF. In this case, kernel is compiled for "real" target arch, > > > so there shouldn't be .BTF.ext in the first place? If that's not the > > > case, then I guess it's a bug in Clang. > > > > > > > > > > > I think a possible fix is to strip .BTF.ext if .BTF is rewritten. > > > > > > > > Best > > > > Lorenz > > > > > > > > -- > > > > Lorenz Bauer | Systems Engineer > > > > 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK > > > > > > > > www.cloudflare.com > > > > -- > > > > - Arnaldo -- - Arnaldo