From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6F02A0C44; Mon, 12 Apr 2021 17:13:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2B8E3141246; Mon, 12 Apr 2021 17:13:02 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 2948A141245; Mon, 12 Apr 2021 17:12:58 +0200 (CEST) IronPort-SDR: 2tr4sP3tGuMbUsy4I8WSf4mCtNx5O+zIjCc63D2iGhyMOlaWshhVGqzlYxTR276TC4uPhCnkM0 zY24UsG8Mv3g== X-IronPort-AV: E=McAfee;i="6200,9189,9952"; a="194326469" X-IronPort-AV: E=Sophos;i="5.82,216,1613462400"; d="scan'208";a="194326469" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2021 08:12:57 -0700 IronPort-SDR: /mQm18Q00nRPpB57ZWO+UIT5QkBsXUCoGbiZKOaD8U+O8/JGEicO6PVrshfu6O8aqh0jocQpll 8R5RYHXzByhQ== X-IronPort-AV: E=Sophos;i="5.82,216,1613462400"; d="scan'208";a="460199519" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.203.254]) ([10.213.203.254]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2021 08:12:53 -0700 To: David Marchand Cc: Thomas Monjalon , Raslan Darawsheh , Tal Shnaiderman , "dev@dpdk.org" , Matan Azrad , Asaf Penso , Wisam Monther , "stable@dpdk.org" , Bruce Richardson References: <20210411122136.2560-1-talshn@nvidia.com> <3237657.no5xmyL5GM@thomas> <63ee5eb4-0388-87a5-683f-007d47180bb5@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <2929f176-6b00-73ea-d5fa-a89e0e5a8bed@intel.com> Date: Mon, 12 Apr 2021 16:12:50 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] common/mlx5: fix missing __rte_internal tags in exported functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 4/12/2021 2:54 PM, David Marchand wrote: > On Mon, Apr 12, 2021 at 3:35 PM Ferruh Yigit wrote: >> >> On 4/12/2021 2:06 PM, Thomas Monjalon wrote: >>> 12/04/2021 14:59, Ferruh Yigit: >>>> On 4/12/2021 12:25 PM, Raslan Darawsheh wrote: >>>>> Hi, >>>>> >>>>> From: Tal Shnaiderman >>>>>> >>>>> Removed __ from the commit title to fix wrong headline format issue. >>>>> >>>>>> Several functions introduced in the addition of the Windows support to >>>>>> mlx5 were missing the __rte_internal tag although being exported. >>>>>> >>>>>> Fixes: 1552fb287166 ("common/mlx5: add alloc/dealloc PD on Windows") >>>>>> Fixes: 1969ee424405 ("common/mlx5: add UMEM reg/dereg functions on >>>>>> Windows") >>>>>> Fixes: ba420719823c ("common/mlx5: add reg/dereg MR on Windows") >>>>>> Cc: stable@dpdk.org >>>>>> >>>>>> Signed-off-by: Tal Shnaiderman >>>>> >>>>> Patch applied to next-net-mlx, >>>>> >>>> >>>> Can we merge this directly to main repo? >>>> Since debug build is broken without it. >>> >>> Which debug option? >>> It is broken since when? >>> >>> >> >> "meson --buildtype=debug build && ninja -C build" is broken [1], I thought that >> is why this patch is done at first place. >> Some checks are done now only in the debug mode, since checks are reduced to >> developer mode [2]. > > I don't think [2] has something to do with it. > > The symbols fixed here are inlined. > In release (and debugoptimized) modes, I can see no trace of them in the .o > > $ nm build/drivers/librte_common_mlx5.a |grep umem_reg > U mlx5dv_devx_umem_reg > 0000000000000410 t mlx5_glue_devx_umem_reg > > While in debug mode: > $ nm build.debug/drivers/librte_common_mlx5.a |grep umem_reg > 00000000000000b9 t mlx5_os_umem_reg > ^^^^^^^^^^^^^^^^^^ > U mlx5dv_devx_umem_reg > 0000000000001578 t mlx5_glue_devx_umem_reg > > > The symbol check then catches mlx5_os_umem_reg wrt the version.map and > complains mlx5_os_umem_reg is not tagged internal. > > Got it, if so this is not related to [2] as you said, but related to the debug mode build, thanks for clarification.