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 4016E438D2; Mon, 15 Jan 2024 17:17:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD3A4402AC; Mon, 15 Jan 2024 17:17:05 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id C9865402A2 for ; Mon, 15 Jan 2024 17:17:03 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 14FCF20C80BA; Mon, 15 Jan 2024 08:17:03 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 14FCF20C80BA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1705335423; bh=/nAJZ9fOws/2nf/10GnvyRSExnkZuRxFaL/J31Kh6y4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J+SHiHRFcdMLXky7F2MSgvlEAPTOc7MR2HUElKikxTJqWOQVkg83aitKXSzr2mMO8 lqzAllaws8qIHtjMIjRJTkcNtN3qzMg/lcpjKP4H9Z2EH+r4TiN0jqourT18hZ0cG6 vE6J9t2zPfTlcZrJ7kaQ2J5koMv6AlC4lprfpXD0= Date: Mon, 15 Jan 2024 08:17:03 -0800 From: Tyler Retzlaff To: David Marchand Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Bruce Richardson , dev@dpdk.org Subject: Re: [PATCH] build: fix linker warnings about undefined symbols Message-ID: <20240115161703.GA382@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> <20240112201102.GA21063@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35E9F14E@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 Mon, Jan 15, 2024 at 09:56:45AM +0100, David Marchand wrote: > On Fri, Jan 12, 2024 at 9:49 PM Morten Brørup wrote: > > > 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). > > Versioning a symbol means you are exporting it, is it not that simple? > So I don't see the need for annotating about symbol visibility. > > > > > > > > just thought a more unified approach for all might appeal. > > > > Assuming that we truly want DPDK to support Windows, a more unified approach is a reasonable ask. > > > > If we can eliminate the technical obstacles, we should pursue it. > > IIUC, we still need a "default" version script, as the linker needs > one to declare version nodes, and so we have a catch all for > unversioned symbols. > > $ cat symver.c > __attribute__ ((__symver__ ("api1@DPDK_23"))) > int old_api1(void) { return 0; } > > __attribute__ ((__symver__ ("api1@@DPDK_24"))) > int api1(void) { return 0; } > > __attribute__ ((__symver__ ("api2@@DPDK_24"))) > int api2(void) { return 0; } > > int api3(void) { return 0; } > > $ cat symver.map > DPDK_23 { }; > DPDK_24 { }; > EXPERIMENTAL { }; > INTERNAL { > local: *; > }; > > $ gcc -o symver.o -fPIC -Wall -Werror -c symver.c && gcc -o > libsymver.so -shared -fPIC -Wl,--version-script symver.map symver.o && > readelf -s libsymver.so | grep api > 5: 0000000000001104 11 FUNC GLOBAL DEFAULT 13 api1@@DPDK_24 > 7: 00000000000010f9 11 FUNC GLOBAL DEFAULT 13 api1@DPDK_23 > 9: 000000000000110f 11 FUNC GLOBAL DEFAULT 13 api2@@DPDK_24 > 13: 00000000000010f9 11 FUNC LOCAL DEFAULT 13 old_api1 > 15: 0000000000001104 11 FUNC LOCAL DEFAULT 13 api1 > 16: 000000000000111a 11 FUNC LOCAL DEFAULT 13 api3 > 19: 000000000000110f 11 FUNC LOCAL DEFAULT 13 api2 > 24: 0000000000001104 11 FUNC GLOBAL DEFAULT 13 api1@@DPDK_24 > 29: 00000000000010f9 11 FUNC GLOBAL DEFAULT 13 api1@DPDK_23 > 31: 000000000000110f 11 FUNC GLOBAL DEFAULT 13 api2@@DPDK_24 > > > > > > We may have to sacrifice some "nice to have" advantages of the version.map files along the way, such as having easy access to the list of experimental functions in the version.map file. > > Developers lose the single location for versioning information, but we > already have some scripts to help list symbols from a given version. > We may have to enhance them. > But I don't think we would lose features. > > The devil is probably in the details, though :-). so my mention of using visibility was more about changes that need to be made to handle windows dso/dll and wondering if a macro based approach would result in something unified for both windows and unix targets. today as you know we use a .map as an authoritative source for the exported symbols and translate the contents of the .map to a .def for the windows linker. going forward to fix dso/dll on windows i'll need to do 2 things. * exclusive export of a subset of symbols for windows only * annotation of certain data symbols with type information since the .map is authoritative i can't just plant either of the above into the .map in order to pass it through to the generated .def file. * we could maintain a mostly duplicated copy of .def and stop generating it allowing the above additions for windows only. * we could go hybrid approach where some of the windows symbols are listed in the .map and some of them are macros in the code. * we could move to some single authoritative source that isn't just defacto default of a toolchain and generate both .map and .def * we could move to visibility and symbol marking with macros in the code for all symbols, of course the expansion is still conditional but you could reasonably grep the tree to generate a full set of exported names. if the suggestion to use visibility and macros for both isn't popular i'm most likely to look at the hybrid approach since i don't have a lot of interest in trying to mangle things into comments of the .map for .def generation and don't think inventing a new common/authoritative format and maintaining a .map and .def generator is interesting. i'm open to input, so just fishing for others who have stronger opinions. ty > > -- > David Marchand