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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 0BDEFC43603 for ; Wed, 11 Dec 2019 18:04:03 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9B9CD205C9 for ; Wed, 11 Dec 2019 18:04:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B9CD205C9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aurel32.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47Y4Yr52bCzDqBl for ; Thu, 12 Dec 2019 05:04:00 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aurel32.net (client-ip=2001:bc8:30d7:100::1; helo=hall.aurel32.net; envelope-from=aurelien@aurel32.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=aurel32.net Received: from hall.aurel32.net (hall.aurel32.net [IPv6:2001:bc8:30d7:100::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47Y1r06CZrzDqWq for ; Thu, 12 Dec 2019 03:01:02 +1100 (AEDT) Received: from aurel32 by hall.aurel32.net with local (Exim 4.92) (envelope-from ) id 1if4Pk-0008An-F6; Wed, 11 Dec 2019 17:00:36 +0100 Date: Wed, 11 Dec 2019 17:00:36 +0100 From: Aurelien Jarno To: Justin Forbes Subject: Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils Message-ID: <20191211160036.GV2974@aurel32.net> Mail-Followup-To: Justin Forbes , Thadeu Lima de Souza Cascardo , 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 , debian-kernel@lists.debian.org References: <20191201195728.4161537-1-aurelien@aurel32.net> <87zhgbe0ix.fsf@mpe.ellerman.id.au> <20191202093752.GA1535@localhost.localdomain> <20191210222553.GA4580@calabresa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thadeu Lima de Souza Cascardo , Song Liu , Daniel Borkmann , "open list:BPF $Safe dynamic programs and tools$" , linuxppc-dev@lists.ozlabs.org, Alexei Starovoitov , LKML , Yonghong Song , "open list:BPF $Safe dynamic programs and tools$" , Andrii Nakryiko , Martin KaFai Lau , debian-kernel@lists.debian.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 2019-12-11 09:33, 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] It seems that in your case the localentry part is added after the symbol name. That doesn't match what is done in upstream binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;hb=refs/heads/master#l11485 Which version of binutils are you using? It looks like your version has been modified to workaround this exact issue. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net