From: Bruce Richardson <bruce.richardson@intel.com>
To: Aaron Conole <aconole@redhat.com>
Cc: konstantin.ananyev@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] bpf: remove use of weak functions
Date: Wed, 10 Apr 2019 15:27:39 +0100 [thread overview]
Message-ID: <20190410142739.GF718@bricha3-MOBL.ger.corp.intel.com> (raw)
Message-ID: <20190410142739.ZSELb9jRZ250bSXrXsrlSRpy8Ixd0ojzKO5hXDnVg_I@z> (raw)
In-Reply-To: <f7tpnpueyxm.fsf@dhcp-25.97.bos.redhat.com>
On Wed, Apr 10, 2019 at 10:07:33AM -0400, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson@intel.com> writes:
>
> > Weak functions don't work well with static libraries and require the use of
> > "whole-archive" flag to ensure that the correct function is used when
> > linking. Since the weak function is only used as a placeholder within this
> > library alone, we can replace it with a non-weak version protected using
> > preprocessor ifdefs.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> I agree with dropping the weak implementations.
>
> But, can't we adjust the order of objects when building with multiple
> strong definitions and the linker will choose the first? I know this
> works for the GNU linker.
>
> I do find this information to help support this statement:
>
> https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries
>
> Unfortunately, I don't find anything in the C standard to govern entity
> precedence. This means it isn't something that works across linker
> implementations (but compatible implementations like clang will maintain
> that behavior).
>
It may be possible, but I'd be worried about the fragility of the support.
Is it a good idea to have multiple implementations of a function in a .a
file. Without running the resulting binary, we have no way of knowing the
correct function was picked up. At least with the weak versions, we can see
from nm what is used.
/Bruce
next prev parent reply other threads:[~2019-04-10 14:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 13:45 [dpdk-dev] [PATCH 0/2] remove use of weak functions from libraries Bruce Richardson
2019-04-10 13:45 ` Bruce Richardson
2019-04-10 13:45 ` [dpdk-dev] [PATCH 1/2] acl: remove use of weak functions Bruce Richardson
2019-04-10 13:45 ` Bruce Richardson
2019-04-10 13:54 ` Aaron Conole
2019-04-10 13:54 ` Aaron Conole
2019-04-10 14:02 ` Bruce Richardson
2019-04-10 14:02 ` Bruce Richardson
2019-04-10 14:08 ` Aaron Conole
2019-04-10 14:08 ` Aaron Conole
2019-04-10 14:57 ` Ananyev, Konstantin
2019-04-10 14:57 ` Ananyev, Konstantin
2019-04-10 13:45 ` [dpdk-dev] [PATCH 2/2] bpf: " Bruce Richardson
2019-04-10 13:45 ` Bruce Richardson
2019-04-10 14:07 ` Aaron Conole
2019-04-10 14:07 ` Aaron Conole
2019-04-10 14:27 ` Bruce Richardson [this message]
2019-04-10 14:27 ` Bruce Richardson
2019-04-10 14:57 ` Ananyev, Konstantin
2019-04-10 14:57 ` Ananyev, Konstantin
2019-05-27 14:13 ` [dpdk-dev] [PATCH 0/2] remove use of weak functions from libraries David Marchand
2019-05-27 15:41 ` Bruce Richardson
2019-05-27 20:57 ` Aaron Conole
2019-05-28 8:06 ` Bruce Richardson
2019-06-05 14:41 ` Thomas Monjalon
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=20190410142739.GF718@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.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).