From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 62015A0487 for ; Mon, 1 Jul 2019 21:27:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 10B941B9E5; Mon, 1 Jul 2019 21:27:27 +0200 (CEST) Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) by dpdk.org (Postfix) with ESMTP id 84F611B9E3 for ; Mon, 1 Jul 2019 21:27:25 +0200 (CEST) Received: by mail-vs1-f68.google.com with SMTP id r3so1808639vsr.13 for ; Mon, 01 Jul 2019 12:27:25 -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=2jA2IENQHbJCPqCe+sqsp+Qee07dYINMnDzJsYMT+9c=; b=Ci8p/I8BwDAHuLJ2gYOb5B7zcj7YjqtWRtNgORvo4EF8VN+TxJ33w/7ms+iENvzICJ bEzvx1XDs9NKo5umWH5tld6RkVokv6Rsg3CnWA2TH0cb6lPL7gqaXSfSqQUjfncL+kFt IDu7CTVY5s7esmiUr49KbNcc3A9nkKLC3SO6W/ZsvxA488ariW5XsSUr5QiqOTfAWg6K b71VeD858X004RoxAHIOrWN7ErkDCceA7seIfRotMMWZVXkhQIAl5HUtLde1i1FYvIwm qwzyOnWlJbya4xju2+9WA7vIjdAdzU9nwdBBDD7d1wXKlGhPzU91RjLFlqjjjFnW0wb/ jO8A== X-Gm-Message-State: APjAAAWDpcbCTfBx7/pdxMMuRlF4WrOHhx2H0mcFRpV0Wze2dbsRGBeO CBd+rtGBe7aQE4zWaV9DZzUs0Icjy5uAgHxa0cypWA== X-Google-Smtp-Source: APXvYqz9QLqQhB6/wVlfWKFUSmlQbrzQBa/BXWicfYgg2ScVg3TABjH9ui9LzgpVMmmVYE+Azk2Q+7UcyLnC4LjLy50= X-Received: by 2002:a67:e9ca:: with SMTP id q10mr15806867vso.105.1562009244954; Mon, 01 Jul 2019 12:27:24 -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: From: David Marchand Date: Mon, 1 Jul 2019 21:27:14 +0200 Message-ID: To: Ferruh Yigit Cc: Bruce Richardson , Thomas Monjalon , dev , Neil Horman , Adrien Mazarguil , Stephen Hemminger , Harry Van Haaren 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 5:30 PM Ferruh Yigit wrote: > On 7/1/2019 3:36 PM, David Marchand wrote: > > > > > > 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? > > This is the sample disassembler of one of the "." functions [1], it looks > like > this notation is used by compiler to prepend some code at the very begging > of > the function, Harry (cc'ed) let me know this is may be security feature, > not a > defect of compiler :) > > So briefly, it looks like compiler can add this "." version of the symbols > to > the ".text.experimental" section, I believe the solution is detect this > notation > and handle it. What do you think? > Iiuc, we would skip the symbols finishing with a '.', is this all? -- David Marchand