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 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 C0E0EC433DF for ; Wed, 24 Jun 2020 19:12:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A445C2077D for ; Wed, 24 Jun 2020 19:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593025923; bh=BdZ+BbQ3gQqk4CBZyU1RM2aZLq1Vb4GkBXlI5xkOiE0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=TYBKEnvRJLPV590jZdMk+HIDC2qljD5VRjD3vxHMCt1KnnnVs/ZHiYpvnU/BtgsBD fYRn/dvPseTWgAqOhcGGNTf1P2wJPizJT4T0njdPufWcvBsTQtCptkOcOJaclB3BxA 0BQBpvKL6I7i8DDLHqaCALfab7SaKTMSPdXzeloI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404915AbgFXTMD (ORCPT ); Wed, 24 Jun 2020 15:12:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:58218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404744AbgFXTMD (ORCPT ); Wed, 24 Jun 2020 15:12:03 -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 D637F20702; Wed, 24 Jun 2020 19:12:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593025922; bh=BdZ+BbQ3gQqk4CBZyU1RM2aZLq1Vb4GkBXlI5xkOiE0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nDT4h6DQy2BhIzbAE1UNZGHNxVeWc5J0MQm7vgtoAP7Ni405DNJY0U1vUu8+zBoGC m/1JORFL4KLn3jjl1LUMKSLtXi4VE2R2tym5jQZv0Tc7DCqmjdHky0KzMiarIGBGWT 22+xL7XDMjbq7cbSXggTNb6MS0oVGgZ/xXOxT9Lo= Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id B0F8E405FF; Wed, 24 Jun 2020 16:11:59 -0300 (-03) Date: Wed, 24 Jun 2020 16:11:59 -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: <20200624191159.GB25807@kernel.org> References: <20200624175754.GD20203@kernel.org> <20200624185737.GA25807@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 12:06:24PM -0700, Andrii Nakryiko escreveu: > On Wed, Jun 24, 2020 at 11:57 AM Arnaldo Carvalho de Melo > wrote: > > > > 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. > > Can't we check ELF's target machine and reject if it's a BPF one? I think there is value in allowing pahole to convert DWARF to BTF even for a BPF target object file, say in some case people may think clang is not generating correct BTF so one may want to see what pahole generates and compare. > Someday we might also support "cross-compilation" to be able to dedup > arm ELF from x86 machine. It's sort of ok today for little-endian > ARMs, so maybe not outright reject if architecture is not the same as > the local one? I think outright reject if arch is not t he same it not necessary. We may warn the user that using -g in clang is the preferred method for generating BTF, wdyt? - Arnaldo > > > > - 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 -- - 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 16:11:59 -0300 Message-ID: <20200624191159.GB25807@kernel.org> References: <20200624175754.GD20203@kernel.org> <20200624185737.GA25807@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 12:06:24PM -0700, Andrii Nakryiko escreveu: > On Wed, Jun 24, 2020 at 11:57 AM Arnaldo Carvalho de Melo > wrote: > > > > 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. > > Can't we check ELF's target machine and reject if it's a BPF one? I think there is value in allowing pahole to convert DWARF to BTF even for a BPF target object file, say in some case people may think clang is not generating correct BTF so one may want to see what pahole generates and compare. > Someday we might also support "cross-compilation" to be able to dedup > arm ELF from x86 machine. It's sort of ok today for little-endian > ARMs, so maybe not outright reject if architecture is not the same as > the local one? I think outright reject if arch is not t he same it not necessary. We may warn the user that using -g in clang is the preferred method for generating BTF, wdyt? - Arnaldo > > > > - 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 -- - Arnaldo