DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org
Subject: Re: [PATCH] build: fix linker warnings about undefined symbols
Date: Mon, 15 Jan 2024 09:56:45 +0100	[thread overview]
Message-ID: <CAJFAV8wfg2ZuZ--LVp32ZMZr3Kyc23ix2oXaqdOt_Vm_=XWGCQ@mail.gmail.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F14E@smartserver.smartshare.dk>

On Fri, Jan 12, 2024 at 9:49 PM Morten Brørup <mb@smartsharesystems.com> 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 :-).


-- 
David Marchand


  parent reply	other threads:[~2024-01-15  8:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 15:01 Bruce Richardson
2024-01-10 16:58 ` Tyler Retzlaff
2024-01-11  9:38   ` Morten Brørup
2024-01-11  9:48     ` Bruce Richardson
2024-01-12 20:11       ` Tyler Retzlaff
2024-01-12 20:49         ` Morten Brørup
2024-01-12 22:22           ` Stephen Hemminger
2024-01-15  8:56           ` David Marchand [this message]
2024-01-15 16:17             ` Tyler Retzlaff
2024-02-18 17:38   ` Thomas Monjalon
2024-02-20 17:02     ` Tyler Retzlaff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJFAV8wfg2ZuZ--LVp32ZMZr3Kyc23ix2oXaqdOt_Vm_=XWGCQ@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=roretzla@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).