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 641AFC433DF for ; Wed, 24 Jun 2020 17:23:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36A9920823 for ; Wed, 24 Jun 2020 17:23:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593019434; bh=miVQth6ABM24hU+hhLIcj8DIJS2NZK9J6PN4sLx3d5E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=zJ4h6bu1xvxLqKG/ukIpQsybA8ttqT4lX04vlhPM/7vTxwCEymm8h66ZywAuZJzdj LJUMTqDrQC+d7hdtMnH4nh+4oApH/RhF/pqhHYmTiNXkEOLnV8pERzfaS5Ia9u1fgd P7ZlhprvXgJzZFMf++3rzWVO/CDik6PPwe9UJgUE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405444AbgFXRXx (ORCPT ); Wed, 24 Jun 2020 13:23:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:40898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405318AbgFXRXx (ORCPT ); Wed, 24 Jun 2020 13:23:53 -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 E83052078D; Wed, 24 Jun 2020 17:23:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593019433; bh=miVQth6ABM24hU+hhLIcj8DIJS2NZK9J6PN4sLx3d5E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t0UtHl7xpO5+H9Bza1SBwpN5hUENsJBWNKz27FCpXBObRJ3o+wCMhbkB0CLDnhZ78 GGBq/xheEbQiB03YvlD16PAgZpOZlEN0UpOD4vExzkY/yLZKbzKU3QX8hfIuSXlLPa HPpMdflauza7R7KcfogG9T4/ldeYh2gNOR+V6Ptw= Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 097D5405FF; Wed, 24 Jun 2020 14:23:50 -0300 (-03) Date: Wed, 24 Jun 2020 14:23:50 -0300 From: Arnaldo Carvalho de Melo To: Lorenz Bauer Cc: bpf , dwarves@vger.kernel.org, kernel-team Subject: Re: pahole generates invalid BTF for code compiled with recent clang Message-ID: <20200624172350.GB20203@kernel.org> References: <20200624160659.GA20203@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 05:22:59PM +0100, Lorenz Bauer escreveu: > On Wed, 24 Jun 2020 at 17:07, Arnaldo Carvalho de Melo wrote: > > > > Em Wed, Jun 24, 2020 at 12:05:50PM +0100, Lorenz Bauer escreveu: > > > 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. > > > > > 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 think a possible fix is to strip .BTF.ext if .BTF is rewritten. > > > > Agreed. > > Longer term pahole needs to generate the .BTF.ext from DWARF, but then, > > if clang is generating it already, why use pahole -J? > Beats me, but then sometimes you don't have control over the workflow, see > my v4.19 kernel example. > > Does clang do deduplication for multi-object binaries? > > Also its nice to see that the BTF generated ends up with the same > > sha1sum, cool :-) > Unfortunately it's the .BTF.ext section that has the same sha1, because > pahole doesn't touch it ;( My bad... I guess I saw what I wanted to see... ;-\ - 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 14:23:50 -0300 Message-ID: <20200624172350.GB20203@kernel.org> References: <20200624160659.GA20203@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: Lorenz Bauer Cc: bpf , dwarves-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-team List-Id: dwarves@vger.kernel.org Em Wed, Jun 24, 2020 at 05:22:59PM +0100, Lorenz Bauer escreveu: > On Wed, 24 Jun 2020 at 17:07, Arnaldo Carvalho de Melo wrote: > > > > Em Wed, Jun 24, 2020 at 12:05:50PM +0100, Lorenz Bauer escreveu: > > > 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. > > > > > 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 think a possible fix is to strip .BTF.ext if .BTF is rewritten. > > > > Agreed. > > Longer term pahole needs to generate the .BTF.ext from DWARF, but then, > > if clang is generating it already, why use pahole -J? > Beats me, but then sometimes you don't have control over the workflow, see > my v4.19 kernel example. > > Does clang do deduplication for multi-object binaries? > > Also its nice to see that the BTF generated ends up with the same > > sha1sum, cool :-) > Unfortunately it's the .BTF.ext section that has the same sha1, because > pahole doesn't touch it ;( My bad... I guess I saw what I wanted to see... ;-\ - Arnaldo