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.0 required=3.0 tests=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 B03F5C0650E for ; Mon, 1 Jul 2019 14:37:01 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 4EB1420659 for ; Mon, 1 Jul 2019 14:37:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EB1420659 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BD8031B9D9; Mon, 1 Jul 2019 16:36:56 +0200 (CEST) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by dpdk.org (Postfix) with ESMTP id CFB6A1B9CC for ; Mon, 1 Jul 2019 16:36:54 +0200 (CEST) Received: by mail-vk1-f180.google.com with SMTP id f68so2745355vkf.5 for ; Mon, 01 Jul 2019 07:36:54 -0700 (PDT) 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=Q9qJJaM4mPzpfN8uUYu2WkMX7UCM6ChyxYoEV2mNSpc=; b=EKt7wFm/wYFxj40dA150+nb3iI8W+pBL0EaByEi4xBggwHiHqyf5PnAYkg2X/QicYH on3Iy2YfqwW5T3QJlYKksnCViXxcg2i8snPRi8f3gcNSVE5jPMNzVA/PYn+T49nf03Te 7C55nhmCo95hPyRrHiveECowbXYmf0GESm9dMKKpe8A7rRcwEYDujG4Dw+TdQ+xynNfi 6GAaiApb3YMWeu5QYcltzI+iCZNTsujBR7+HE3gNMqcjV48qauNgmaMHnknIZe+eq+c2 3Gi97kdOKvWCm0aiytRxxf4p9h7KYdQmKQnmB5oq5AulYQLgu3J8xzcD/+/OXxMhyA1F pjKg== X-Gm-Message-State: APjAAAWj2SWAgBcTmFxTdXAkCebTWfrkd94hmW4KKav9MJBDgC9Vpl+O 5bM404dEfP73TC8siN1YzCvaxdj122xdI6CdYofuaA== X-Google-Smtp-Source: APXvYqyRvQRS1oJ/Ma0TG/D/w/rXaCu/V01Idi/A2+uBjp/Dt3jaQx/70tDCOscB5ZIvZZ82gPUSvP9zdjJJCamlk8Q= X-Received: by 2002:a1f:1185:: with SMTP id 127mr8241085vkr.85.1561991813199; Mon, 01 Jul 2019 07:36:53 -0700 (PDT) MIME-Version: 1.0 References: <1561635235-22238-1-git-send-email-david.marchand@redhat.com> <1561809533-6545-1-git-send-email-david.marchand@redhat.com> <2123522.W70hLPZofc@xps> <47b0afe9-96ba-eafd-cf37-08c69742b15e@intel.com> In-Reply-To: <47b0afe9-96ba-eafd-cf37-08c69742b15e@intel.com> From: David Marchand Date: Mon, 1 Jul 2019 16:36:41 +0200 Message-ID: To: Ferruh Yigit , Bruce Richardson Cc: Thomas Monjalon , dev , Neil Horman , Adrien Mazarguil , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 00/10] experimental tags fixes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Jul 1, 2019 at 4:15 PM Ferruh Yigit wrote: > On 6/29/2019 6:06 PM, Thomas Monjalon wrote: > > 29/06/2019 13:58, David Marchand: > >> Following the build error reported by Aaron [1], I noticed that some > >> experimental functions could go unnoticed because of a gcc peculiarity. > >> > >> To catch those, I went and added a new check on the object files to > >> ensure that any experimental api flagged in the map files is really > >> exported as such. > >> > >> Then went with my previous idea of only adding the tags on the functions > >> prototypes and enforcing it (a new check in checkpatches.sh). > >> And finally enforcing that the __rte_experimental tag is always the > first > >> part of a function prototype which seems to work with both gcc and > clang. > > > > Applied, thanks > > > > > Getting an odd build error with "i686-native-linuxapp-icc" [1]. > Beware of the "." at the end: "rte_flow_conv." > > Objdump shows two symbols with one "." at the end and one without it [2]. > > And this seems not the problem of only experimental APIs [3]. But this is > only > happening with "i686-native-linuxapp-icc". > > Do you have any idea what is going on here? > > Looked at rte_flow_conv, and I can not see anything special about it. There might be a subtility in the way symbol names are chosen by ICC. Can ICC guys look at this and give us some enlightment? -- David Marchand