Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp877455ybl; Wed, 11 Dec 2019 08:53:48 -0800 (PST) X-Google-Smtp-Source: APXvYqwnmm3BdKM4Ac/MAn1332sSVhVqb1/1M6IjHb6m/vSEGjeHG+4AMLyHC4U9cE4WlUhemkZQ X-Received: by 2002:a05:6830:1c81:: with SMTP id v1mr3056907otf.83.1576083228835; Wed, 11 Dec 2019 08:53:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576083228; cv=none; d=google.com; s=arc-20160816; b=y4/rBdt6DHANj1vFrycD+DOQWqZaBZKkyiQwnbHqYoDCvz8sSt0lvV5Ign/aYxE+uk rBG1+nt5mcLhVprjoJJlAqb3ZOcXr4HZeitTNZw84Tbvs1epiLP8WDk0AmpJGDmIRqod q06xysSJ4Gxab3rOy4Zi0LdOlMc831uC4rcbFVgI1H6wjYtM4cwOZs3x/Z1SrGSgtpYq VzMs95HU51EbzuCSSotxFxA/qiUpstej1jmbXCd1EThynKpIQHcO8DeQmssyBg1VKOdf lMfGz5MfTAJB+dRw0IoGHt6aUogi8RN5jDVw5tQCbbnNbB7tmN355dVM2Hs901FloYOQ OxNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fl7Is/227Xkupce2trJJJrsnTq1Teu4U8XUaGw3152I=; b=YdBKngUDNFQ/T2bb0xNIarbniWw9BhnLGJ7FHjtpl02IQpCMri7mOSjuguOJ1wh5ud Rt0TqtdMFT3x9AXhl24Qhdp+Krz5UlGqfPHONIw8qc4TcZ/gqU3KZH8dDgklZNTobD5B skOgSoEr6s5O8/aBCbr4NJjQxIcL0/bNey2nplePTP17TwYJIw0VFD43e8ehzV3NhwsD t0ca9NipXdHYxkaWMXzoBtKPXLEfIMUf4LZMXqv+qxNOiFuhpgdS7KF7iixDw6Z2/t4F 9866crA0MEvlkHA7ixNqItIskvti58GCKOqUeoyA+9AwnG911zRF82MzjI7Az+gqFV35 wPqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxtx.org header.s=google header.b="cWBLp/GP"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m19si1369023oig.91.2019.12.11.08.53.30; Wed, 11 Dec 2019 08:53:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxtx.org header.s=google header.b="cWBLp/GP"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730314AbfLKQxB (ORCPT + 99 others); Wed, 11 Dec 2019 11:53:01 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:36455 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730058AbfLKQxA (ORCPT ); Wed, 11 Dec 2019 11:53:00 -0500 Received: by mail-wm1-f68.google.com with SMTP id p17so7742770wma.1 for ; Wed, 11 Dec 2019 08:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxtx.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fl7Is/227Xkupce2trJJJrsnTq1Teu4U8XUaGw3152I=; b=cWBLp/GPZGoKuBJ8dsv+TMZRrbzBXSstVTLxIXi/BlmooE6meRq08qQmG9rZWE5M9o GXWeAMB/Sex87iLqvlE0lzp+xzgwpzYZDUqI2SAb08d7tXVBNJcwqEdG9fI5zJhjNXBk 4AzRV2ZAnelvnFparpQcFZvUl54U4nGcDFBqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fl7Is/227Xkupce2trJJJrsnTq1Teu4U8XUaGw3152I=; b=VqJ98ASJnfdJFaAUMjRci0Hnmg597lAcfrkFv2fgBcSJcle5UPn3f9scnt6eh7wDmj U/O/GyffjSYXAiwqhpINOBfasTEZ2CxXXKzXBEYwC+85oy+qJaUsY1qeThHH1RQbHY04 di1WEnZChYCfHNpm82WlSZTV7quKTDlfLekwTeiSbiftiUCcJAnBK88YCkJ2TL8XqFRl fc67y0qQaF8STPiDBnOoa3QbeTXfbDnL9qXLrRooGnDL56NX2WqivYSeAfRHRLusklfC wTRycvr6d8Tk2qg8MC9rEDUbLcPQmRPxp6uc2OXpZ3i5Ot2QwZqe6sp6aKi3gZDIpjgT lQ1w== X-Gm-Message-State: APjAAAUmmqjOhbH6Yp6K5lACjm4EMKVapgCdwP0VcG3LY2OKcE8MfERb snz3u01+a9xKv83rY4pe/EFy6jfZbno4Dp0b7oQz7A== X-Received: by 2002:a7b:c389:: with SMTP id s9mr841991wmj.7.1576083177581; Wed, 11 Dec 2019 08:52:57 -0800 (PST) MIME-Version: 1.0 References: <20191201195728.4161537-1-aurelien@aurel32.net> <87zhgbe0ix.fsf@mpe.ellerman.id.au> <20191202093752.GA1535@localhost.localdomain> <20191210222553.GA4580@calabresa> <20191211160133.GB4580@calabresa> In-Reply-To: <20191211160133.GB4580@calabresa> From: Justin Forbes Date: Wed, 11 Dec 2019 10:52:46 -0600 Message-ID: Subject: Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils To: Thadeu Lima de Souza Cascardo Cc: Daniel Borkmann , Song Liu , Andrii Nakryiko , Alexei Starovoitov , LKML , "open list:BPF (Safe dynamic programs and tools)" , Yonghong Song , "open list:BPF (Safe dynamic programs and tools)" , linuxppc-dev@lists.ozlabs.org, Martin KaFai Lau , Aurelien Jarno , debian-kernel@lists.debian.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 11, 2019 at 10:01 AM Thadeu Lima de Souza Cascardo wrote: > > On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote: > > On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo > > wrote: > > > > > > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote: > > > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote: > > > > > > > > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote: > > > > > > Aurelien Jarno writes: > > > > > > > On powerpc with recent versions of binutils, readelf outputs an extra > > > > > > > field when dumping the symbols of an object file. For example: > > > > > > > > > > > > > > 35: 0000000000000838 96 FUNC LOCAL DEFAULT [: 8] 1 btf_is_struct > > > > > > > > > > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to > > > > > > > be computed correctly and causes the checkabi target to fail. > > > > > > > > > > > > > > Fix that by looking for the symbol name in the last field instead of the > > > > > > > 8th one. This way it should also cope with future extra fields. > > > > > > > > > > > > > > Signed-off-by: Aurelien Jarno > > > > > > > --- > > > > > > > tools/lib/bpf/Makefile | 4 ++-- > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > Thanks for fixing that, it's been on my very long list of test failures > > > > > > for a while. > > > > > > > > > > > > Tested-by: Michael Ellerman > > > > > > > > > > Looks good & also continues to work on x86. Applied, thanks! > > > > > > > > This actually seems to break horribly on PPC64le with binutils 2.33.1 > > > > resulting in: > > > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT > > > > match with num of versioned symbols in libbpf.so (184). Please make > > > > sure all LIBBPF_API symbols are versioned in libbpf.map. > > > > > > > > This is the only arch that fails, with x86/arm/aarch64/s390 all > > > > building fine. Reverting this patch allows successful build across > > > > all arches. > > > > > > > > Justin > > > > > > Well, I ended up debugging this same issue and had the same fix as Jarno's when > > > I noticed his fix was already applied. > > > > > > I just installed a system with the latest binutils, 2.33.1, and it still breaks > > > without such fix. Can you tell what is the output of the following command on > > > your system? > > > > > > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $0}' > > > > > > > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" > > -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && > > !/UND/ {print $0}' > > 373: 00000000000141bc 1376 FUNC GLOBAL DEFAULT 1 > > libbpf_num_possible_cpus [: 8] > > 375: 000000000001869c 176 FUNC GLOBAL DEFAULT 1 btf__free > > [: 8] > [...] > > This is a patch on binutils carried by Fedora: > > https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8 > > " b8265c Have readelf display extra symbol information at the end of the line. " > > It has the following comment: > > # FIXME: The proper fix would be to update the scripts that are expecting > # a fixed output from readelf. But it seems that some of them are > # no longer being maintained. > > This commit is from 2017, had it been on binutils upstream, maybe the situation > right now would be different. > > Honestly, it seems the best way out is to filter the other information in the > libbpf Makefile. > > Does the following patch work for you? > > > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile > index 56ce6292071b..e6f99484d7d5 100644 > --- a/tools/lib/bpf/Makefile > +++ b/tools/lib/bpf/Makefile > @@ -145,6 +145,7 @@ PC_FILE := $(addprefix $(OUTPUT),$(PC_FILE)) > > GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \ > cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \ > + sed 's/\[.*\]//' | \ > awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \ > sort -u | wc -l) > VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \ > @@ -217,6 +218,7 @@ check_abi: $(OUTPUT)libbpf.so > "versioned in $(VERSION_SCRIPT)." >&2; \ > readelf -s --wide $(OUTPUT)libbpf-in.o | \ > cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \ > + sed 's/\[.*\]//' | \ > awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'| \ > sort -u > $(OUTPUT)libbpf_global_syms.tmp; \ > readelf -s --wide $(OUTPUT)libbpf.so | \ This patch was against the older version, but when updated for current 5.5-rc1, it does indeed work for me. Thanks, Justin