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 6EBE4438CB; Mon, 15 Jan 2024 09:57:04 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 40E294029F; Mon, 15 Jan 2024 09:57:04 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id AF1D440272 for ; Mon, 15 Jan 2024 09:57:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705309022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kRO2xyztvzZCcVgOO5thxlSkTE94vzo98eFiQOJmTJM=; b=LTDjm2CT+99hxFhTwsp4q3QXCZAazDycJvXl9wua7T1B+TPI5hgrsgpGdmJ/QLhxAZTt8W qHzCiBwlpCNZ8SDTFp5XCC12F8oT//jrOVoo44KQdvLpdISy/uwqx965q3j0bY7Ymf5u93 BNAmjXvh60EFUla/uTN/ZCKmJSZm8EM= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-391-XQr6VDgTMd-5v2N0G2p8PA-1; Mon, 15 Jan 2024 03:57:00 -0500 X-MC-Unique: XQr6VDgTMd-5v2N0G2p8PA-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2ccea28e95aso77206081fa.3 for ; Mon, 15 Jan 2024 00:57:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705309019; x=1705913819; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kRO2xyztvzZCcVgOO5thxlSkTE94vzo98eFiQOJmTJM=; b=QN8JI9mOj2HBNvwYsl2qHB5JMaLW/4JM/eh6CQQy6dc729lyF4CxBWg0CfW7BEiu3T Fetb3P3AJ6KIgsVggjVkgWJl1fjNpQcH31/1c3bunWjAfe7htzrFJJsSclHixBsP0sgN ThYKjBcNmNPmVUttQwsThSNClRV8GSVJ6cePjUXrQaFScPU4opxOpxbcBY0n5dMrD+M4 3Z775F31KuXCOIhq4jPjcjASBgSp2wCg4j7W3QdLcV/d//59E5KkFBgWpRwUmAUXkwXg dSoezG5ETMLUpPS1qircSVcBpVC/+FmVpEsxsvToXps9jrl74jwZtYxo6dgxvC5jy5xl lhCg== X-Gm-Message-State: AOJu0YxzRKGIuIUJae6l2WrI1YpXVGKGODDI7+4P0230hJQ/K4GSHva6 BTRS+yS9vFUnkXkCmxQQ2J3raPiAY8Bo4CgyUy0M+P3+6qMQQyCyYDe0VCULBA8Im5ga0+jTJ++ nctC3F3/EFey74rV5IjHikh0+WWfegZmEe8BUPg== X-Received: by 2002:a2e:9e02:0:b0:2cd:4f03:ad4c with SMTP id e2-20020a2e9e02000000b002cd4f03ad4cmr2336710ljk.80.1705309018933; Mon, 15 Jan 2024 00:56:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IEgVxzudZzTs3T7TwQpS3N1/E3w+ZXWmm8HEwtDx8KYI98OLavrCaSz9EU0GC/WvAXcceUi8dgFn77HdjB5MGU= X-Received: by 2002:a2e:9e02:0:b0:2cd:4f03:ad4c with SMTP id e2-20020a2e9e02000000b002cd4f03ad4cmr2336703ljk.80.1705309018599; Mon, 15 Jan 2024 00:56:58 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F14E@smartserver.smartshare.dk> From: David Marchand Date: Mon, 15 Jan 2024 09:56:45 +0100 Message-ID: Subject: Re: [PATCH] build: fix linker warnings about undefined symbols To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Tyler Retzlaff Cc: Bruce Richardson , dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Fri, Jan 12, 2024 at 9:49=E2=80=AFPM Morten Br=C3=B8rup 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 appro= ach 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.ma= p files along the way, such as having easy access to the list of experiment= al 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 :-). --=20 David Marchand