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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 704CCC433E1 for ; Fri, 15 May 2020 09:17:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3EBDD2065C for ; Fri, 15 May 2020 09:17:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="P4Iii1at" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728005AbgEOJR0 (ORCPT ); Fri, 15 May 2020 05:17:26 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:27949 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727785AbgEOJRZ (ORCPT ); Fri, 15 May 2020 05:17:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589534244; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mnRre2Cx4ihUmsSYvpskeloE4Blh3L+V4XuwzK66mi0=; b=P4Iii1atA6lNryeNNVXerKJ9TF0kR6JPrrspqdkCO34DsixQTq7XZupi7qCG7b5NnGIRF/ n4k4d1R+KCo9t3ys9jxxbH7eFEv2rc12Ob9nLHCCgQOriwIMkDRnHTMH9SFRedVnOM+mzj hrkBBbX7hJccOCKObugHMRJCOdKcqoQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-302-e0TBRx52PWahR22LB9MItA-1; Fri, 15 May 2020 05:17:20 -0400 X-MC-Unique: e0TBRx52PWahR22LB9MItA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 69715835BA8; Fri, 15 May 2020 09:17:17 +0000 (UTC) Received: from krava (unknown [10.40.194.127]) by smtp.corp.redhat.com (Postfix) with SMTP id 7835478B23; Fri, 15 May 2020 09:17:10 +0000 (UTC) Date: Fri, 15 May 2020 11:17:07 +0200 From: Jiri Olsa To: Ian Rogers Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Kajol Jain , Andi Kleen , John Garry , Jin Yao , Kan Liang , Cong Wang , Kim Phillips , Adrian Hunter , Leo Yan , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Stephane Eranian Subject: Re: [PATCH 4/8] libbpf hashmap: Localize static hashmap__* symbols Message-ID: <20200515091707.GC3511648@krava> References: <20200515065624.21658-1-irogers@google.com> <20200515065624.21658-5-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515065624.21658-5-irogers@google.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, May 14, 2020 at 11:56:20PM -0700, Ian Rogers wrote: > Localize the hashmap__* symbols in libbpf.a. To allow for a version in > libapi. > > Before: > $ nm libbpf.a > ... > 000000000002088a t hashmap_add_entry > 000000000001712a t hashmap__append > 0000000000020aa3 T hashmap__capacity > 000000000002099c T hashmap__clear > 00000000000208b3 t hashmap_del_entry > 0000000000020fc1 T hashmap__delete > 0000000000020f29 T hashmap__find > 0000000000020c6c t hashmap_find_entry > 0000000000020a61 T hashmap__free > 0000000000020b08 t hashmap_grow > 00000000000208dd T hashmap__init > 0000000000020d35 T hashmap__insert > 0000000000020ab5 t hashmap_needs_to_grow > 0000000000020947 T hashmap__new > 0000000000000775 t hashmap__set > 00000000000212f8 t hashmap__set > 0000000000020a91 T hashmap__size > ... > > After: > $ nm libbpf.a > ... > 000000000002088a t hashmap_add_entry > 000000000001712a t hashmap__append > 0000000000020aa3 t hashmap__capacity > 000000000002099c t hashmap__clear > 00000000000208b3 t hashmap_del_entry > 0000000000020fc1 t hashmap__delete > 0000000000020f29 t hashmap__find > 0000000000020c6c t hashmap_find_entry > 0000000000020a61 t hashmap__free > 0000000000020b08 t hashmap_grow > 00000000000208dd t hashmap__init > 0000000000020d35 t hashmap__insert > 0000000000020ab5 t hashmap_needs_to_grow > 0000000000020947 t hashmap__new > 0000000000000775 t hashmap__set > 00000000000212f8 t hashmap__set > 0000000000020a91 t hashmap__size > ... I think this will break bpf selftests which use hashmap, we need to find some other way to include this either to use it from libbpf directly, or use the api version only if the libbpf is not compiled in perf, we could use following to detect that: CFLAGS += -DHAVE_LIBBPF_SUPPORT $(call detected,CONFIG_LIBBPF) jirka