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 77E6B438A9; Fri, 12 Jan 2024 21:11:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 05EBE402F0; Fri, 12 Jan 2024 21:11:05 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id A2270402EC for ; Fri, 12 Jan 2024 21:11:03 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 06FB120B3CE4; Fri, 12 Jan 2024 12:11:03 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 06FB120B3CE4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1705090263; bh=fDsMggly7p6ulwB1dZxkOkuSFmliVLJ9b7VhruDIGk8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pzQxZKcjch0w21L3x9vFoe5vlTu9RA5DxLrIP8/oPIKQx+OSsZMDgeZG2u4R0LDP7 7v+OAv/3kT44o6P3EUIh8ndt/Nu4sm5Pj94SHJmSpAymdk2fRw4ya/BlmkaEebckRx aXlnzhaI3EB7YWQ5Vc5Dq/MV49doIkwSRId/8HjI= Date: Fri, 12 Jan 2024 12:11:02 -0800 From: Tyler Retzlaff To: Bruce Richardson Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org Subject: Re: [PATCH] build: fix linker warnings about undefined symbols Message-ID: <20240112201102.GA21063@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240110150103.529080-1-bruce.richardson@intel.com> <20240110165814.GA25069@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35E9F125@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Thu, Jan 11, 2024 at 09:48:33AM +0000, Bruce Richardson wrote: > On Thu, Jan 11, 2024 at 10:38:05AM +0100, Morten Brørup wrote: > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > Sent: Wednesday, 10 January 2024 17.58 > > > > > > On Wed, Jan 10, 2024 at 03:01:03PM +0000, Bruce Richardson wrote: > > > > The default behaviour of "ld.lld" has changed, so it now prints out > > > > warnings about entries in the version.map file which don't exist in > > > > the current build. Since we use our version.map file simply to filter > > > > out the functions we don't want made public, we include in it all > > > > functions across all OS's and builds that we want public if present. > > > > This causes these ld warnings to be emitted, e.g. on BSD, which is > > > > missing functionality found on Linux. For example: > > > > > > > > * hpet functions in EAL > > > > * regexdev enqueue and dequeue burst > > > > * eventdev event_timer functions > > > > > > > > Easiest solution, without major rework of how we use our version.map > > > > files, and without dynamically generating them per-build, is to pass > > > > the --undefined-version flag to the linker, to restore the old > > > > behaviour. > > > > > > > > Signed-off-by: Bruce Richardson > > > > --- > > > > > > Acked-by: Tyler Retzlaff > > > > > > i don't know if has ever been discussed but a way to achieve a similar > > > outcome would be to introduce a visibility macro allowing the data and > > > function symbols to be explicitly made visible while making the build > > > default hidden. > > > > > > https://gcc.gnu.org/wiki/Visibility > > > > This looks interesting! > > Declaring a function "public" directly in its header seems much simpler to manage than having to add it to the version.map file too. > > > > I wonder if function versioning is still supported if using this instead of version.map files? > > Of if there are other relevant reasons for continuing to use the version.map files instead of this? > > > > I don't see in that wiki page and details of how to mark symbols with > different ABI versions. For example, as well as listing what functions are > public, our version.map files also identify the ABI version (e.g. DPDK_24) > they belong to, or whether they are experimental or internal. Having them > all in the version file also makes it easy to see how many experimental > functions we have in each component. you can use symver in combination with visibility default https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html anyway just food for thought, it would get me out of having to hack & enhance the .def from .map generation and unfortunately even with that there are going to be cases where i still have to annotate the actual symbol export in code (for windows). just thought a more unified approach for all might appeal. ty > > /Bruce