[PATCH] eal: fix function versioning with LTO

[Stephen Hemminger]

On Thu, 4 Jun 2026 09:50:25 +0200
David Marchand <david.marchand at redhat.com> wrote:

> On Wed, 3 Jun 2026 at 17:56, Stephen Hemminger
> <stephen at networkplumber.org> wrote:
> >
> > On Wed, 3 Jun 2026 12:01:48 +0200
> > David Marchand <david.marchand at redhat.com> wrote:
> >  
> > > Hello,
> > >
> > > On Wed, 3 Jun 2026 at 00:57, Stephen Hemminger
> > > <stephen at networkplumber.org> wrote:  
> > > >
> > > > When using function versioning and building with Link Time Optimization,
> > > > the compiler does not see the __asm__ annotation of symbols and
> > > > therefore thinks there are two versions of the same symbol.
> > > >
> > > > The fix is to use compiler symver attribute on the function which
> > > > was added in GCC 10. Keep the older method for backward compatibility
> > > > with older compilers.
> > > >
> > > > Bugzilla ID: 1949
> > > > Fixes: e30e194c4d06 ("eal: rework function versioning macros")  
> > >
> > > We never used the symver stuff, so it seems unlikely the issue was
> > > introduced with this rework.
> > >
> > > The fact that clang does not support this attribute is a concern.  
> >
> > Clang doesn't have this problem. It works as is.  
> 
> The Fixes: tag is wrong regardless.
> The issue is probably present since introduction of the versioning
> macros, or introduction of LTO in DPDK (not sure which came first).

Right the Fixes is wrong, will resend without

> 
> 
> > > > Cc: stable at dpdk.org  
> > >
> > > Why do we need to backport?  
> >
> > Well LTO has worked for a long time, it is not experimental just
> > not commonly done since it takes so long to build.
> >
> > We were doing it years ago at MSFT.  
> 
> Well, sorry, but every time I enable LTO, I end up with some warnings somewhere.
> I don't think I am doing stuff really exotic though.

Using LTO has always been extra effort. It is worth it for largish
legacy code because the compiler can crunch things down.

> 
> Looking at bugzilla, we had various fixes for LTO over the years.
> We still have one open bz btw: https://bugs.dpdk.org/show_bug.cgi?id=1709

That bug was fixed a while back. It required addition of hints (__rte_assume)

> 
> Hence my feeling this feature is not something used by many people around.
> And without a CI, we will keep on having to fix bugs/issues.
> 
> 
> > > LTO is kind of experimental, so it seems good enough to reply "not
> > > expected to work in older LTS" if someone reported an issue.
> > >
> > > And in practice, no LTS release call the versioning macros, since a
> > > LTS drops all compatibility.  
> 
> Just to be clear, we don't need fixing the macros in LTS: every time
> we prepare a LTS rc0, we drop any kind of symbol compat.

Agree, this is not LTS related

> > >  
> > > > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>  
> > >
> > > I would like to reproduce, but I can't build main with LTO.
> > > What patches did you apply locally to avoid warnings on the hash library?  
> > I use Debian testing and GCC 15 but shows up on older versions as well
> > I get no warnings building main  
> 
> Building from scratch, I do avoid the warnings I hit yesterday.
> 
> The fix looks correct, my problem is with the form.
> Fixes: tags accuracy is important.
> And I prefer we stick to "It is not broken, don't fix it".

Could argue it is a GCC bug, and applying their desired workaround :-)