Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3267922pxa; Tue, 18 Aug 2020 10:39:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVZVNJgqFToKDyMJJCOYcSlwGxWa8K1ntDznfntaObnTAfma3l+VtC6lpOYURnaayXZUn7 X-Received: by 2002:a17:906:8318:: with SMTP id j24mr20803327ejx.409.1597772394528; Tue, 18 Aug 2020 10:39:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597772394; cv=none; d=google.com; s=arc-20160816; b=OwYrfzjm5ryvcAIM/o3ED+L1WgdCOHf+UchqjMerkdgImaWEUODpmG3YdvfhM8ed56 aPz4TSvFCwrtTG2nsDyaZsQrSxa+OTURL2aBks6Zz0QQv+6c+0jCFTX6wYP/SA4UtQTt LXOpyddtQc2rWc5JD0l+mbMNf7S1qUnXrkZ5B+AZFcgZ73btsTnwx4gWwWowgAIq0RqD H3loRRgRiwW6k3hXLE4RXU1sDc3sXLU5dJCF2nHlC3+2JDvh7fmz+KoA6eskm79z+7aB rRCjZC8DopcbxtWN86HrGRuO12W5XC7TVP08he/fK8ZHgYGFGFWsYYsjxJuXNkLmgTXi 8z4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=jyOcZSnT1IAwxafl5hj7XYYSfgcXErBmCuF4cjVvdPw=; b=scyE0UPKdmwwMZSV8G0pPnJLxGYGYVn1l7UhkLq8PyKtgQDCKeXZvbBDYfCUV9WF7+ R2OhWrg9PMy+ksLrnmi7caT0SRZPE4rRobqc/RffxKF7Vux8G9WtUGp9RNJnvKmUrcul G+w1sn9lGWn5nnAhLhFFOstj7HMvebXcLnUnS80V2S+byCNP4Z+vGw1u+lyGvsvdi9fV 5MSULeLGGAWAuVLadzv4ReVP2vv2DyltBPBpKOLKYezLmV5lbghznt5Ki0yl7UBK1sW6 QMx6ZxN9IAUAbREDdyugK7+nIoO7LZKrcAMm75zyWspvMYjppeLrhq5VbyKHMwZNfjyU /Yow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si13514823eds.493.2020.08.18.10.39.30; Tue, 18 Aug 2020 10:39:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728883AbgHRRgc convert rfc822-to-8bit (ORCPT + 99 others); Tue, 18 Aug 2020 13:36:32 -0400 Received: from wildebeest.demon.nl ([212.238.236.112]:50288 "EHLO gnu.wildebeest.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728532AbgHRRgX (ORCPT ); Tue, 18 Aug 2020 13:36:23 -0400 X-Greylist: delayed 381 seconds by postgrey-1.27 at vger.kernel.org; Tue, 18 Aug 2020 13:36:21 EDT Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 8197F30278CD; Tue, 18 Aug 2020 19:29:56 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 2FDCF401443A; Tue, 18 Aug 2020 19:29:56 +0200 (CEST) Message-ID: Subject: Re: Kernel build error on BTFIDS vmlinux From: Mark Wielaard To: Jesper Dangaard Brouer , Jiri Olsa Cc: "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , sdf@google.com, andriin@fb.com, nickc@redhat.com Date: Tue, 18 Aug 2020 19:29:56 +0200 In-Reply-To: <20200818183318.2c3fe4a2@carbon> References: <20200818105555.51fc6d62@carbon> <20200818091404.GB177896@krava> <20200818105602.GC177896@krava> <20200818134543.GD177896@krava> <20200818183318.2c3fe4a2@carbon> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gnu.wildebeest.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Adding Nick, the binutils maintainer, so we can make sure binutils/elfutils agree on some ELF section compression corner case. On Tue, 2020-08-18 at 18:33 +0200, Jesper Dangaard Brouer wrote: > On Tue, 18 Aug 2020 15:45:43 +0200 > Jiri Olsa wrote: > > > On Tue, Aug 18, 2020 at 12:56:08PM +0200, Jiri Olsa wrote: > > > On Tue, Aug 18, 2020 at 11:14:10AM +0200, Jiri Olsa wrote: > > > > On Tue, Aug 18, 2020 at 10:55:55AM +0200, Jesper Dangaard Brouer wrote: > > > > > > > > > > On latest DaveM net-git tree (06a4ec1d9dc652), after linking (LD vmlinux) the > > > > > "BTFIDS vmlinux" fails. Are anybody else experiencing this? Are there already a > > > > > fix? (just returned from vacation so not fully up-to-date on ML yet) > > > > > > > > > > The tool which is called and error message: > > > > > ./tools/bpf/resolve_btfids/resolve_btfids vmlinux > > > > > FAILED elf_update(WRITE): invalid section alignment > > > > > > > > hi, > > > > could you send your .config as well? > > > > > > reproduced.. checking on fix > > > > I discussed this with Mark (cc-ed) it seems to be a problem > > with linker when dealing with compressed debug info data, > > which is enabled in your .config > > > > it works for me when I disable CONFIG_DEBUG_INFO_COMPRESSED option > > Thanks for finding this! > I confirm that disabling CONFIG_DEBUG_INFO_COMPRESSED fixed the issue. > > > Mark will fix this upstream, meanwhile he suggested workaround > > we can do in resolve_btfids tool, that I'll try to send shortly > > Great! So, the issue is that there is some confusion about the correct alignment of compressed ELF sections. When an ELF section is compressed using gabi-zlib it contains a header (a Elf_Chdr32 or Elf_Chdr64, followed by the compressed data) The header explains how the section data is compressed, what the exploded size is, what the alignment of that uncompressed data is, etc. Because of this header the section data should be aligned to 4 (for 32bit) or 8 (for 64 bit) bytes, but binutils ld sets sh_addralign to 1. [*] elfutils libelf is liberal in what it accepts, and internally fixes up the alignment if it is wrong. Which is why we probably didn't see this before. But it won't let you write out misaligned data like that. Which is slightly confusing, because if you didn't change that section data, it is not immediately clear why you are getting an error. Also if you would decompress the section data to use it and then recompress it elfutils libelf would set sh_addralign correctly for you. But it won't if you don't use the (uncompressed) data. The workaround would be to explicitly set the alignment of the compressed section before writing out the section. Which is what Jiri is now testing. But it would obviously be better if that wasn't necessary. So I'll try to fix libelf so that if it fixes up the alignment when reading the compressed data, it also does that when writing out the data again. But that would only help for a new version of elfutils. So it would be nice if binutils ld could also be fixed to write out compressed sections with the correct alignment. Then hopefully if someone has either a new elfutils or a new binutils it just works without needing any workarounds. Cheers, Mark [*] If this sounds vaguely familiar then that is because we did have a different alignment bug, but for the uncompressed data (which is the alignment set in the compression header): https://bugzilla.redhat.com/show_bug.cgi?id=1678204 That bug was about ch_addralign, this bug is about sh_addralign.