|SUCCESS| eal: fix function versioning with LTO

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Wed Jun 3 03:01:53 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164845

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-06-03

Reviewing patch: eal: fix function versioning with LTO

git sha: 20260602225722.950617-1-stephen at networkplumber.org
Author: Stephen Hemminger <stephen at networkplumber.org>
Subject: eal: fix function versioning with LTO

This patch addresses a Link Time Optimization (LTO) issue with function
versioning by preferring the GCC 10+ symver attribute over inline
assembly when available.

> diff --git a/lib/eal/common/eal_export.h b/lib/eal/common/eal_export.h
> index 7e47d34064..1318e6278d 100644
> --- a/lib/eal/common/eal_export.h
> +++ b/lib/eal/common/eal_export.h

[ ... ]

> +/* Prefer the compiler method of versioning which uses attributes */
> +#if  __has_attribute(symver)

Does this code handle older compilers without __has_attribute() support?
The __has_attribute() feature is itself a compiler extension that may
not be universally available. Should this have a fallback check for
__has_attribute existence?

> +
> +#define RTE_VERSION_SYMBOL(ver, type, name, args) VERSIONING_WARN	\
> +	__attribute__((__symver__(RTE_STR(name) "@DPDK_" RTE_STR(ver)))) \
> +	type name ## _v ## ver args;					\
> +	type name ## _v ## ver args

Can this duplicate declaration cause issues? The macro defines
"type name ## _v ## ver args" twice - once as a declaration and once
as what appears to be a definition. Does this violate the one definition
rule or create multiple definition errors at link time?

> +
> +#define RTE_VERSION_EXPERIMENTAL_SYMBOL(type, name, args) VERSIONING_WARN \
> +	__attribute__((__symver__(RTE_STR(name) "@EXPERIMENTAL")))	\
> +	type name ## _exp args;						\
> +	type name ## _exp args

Same question here - does this duplicate "type name ## _exp args"
declaration cause linker errors?

> +
> +#define RTE_DEFAULT_SYMBOL(ver, type, name, args) VERSIONING_WARN	\
> +	__attribute__((__symver__(RTE_STR(name) "@@DPDK_" RTE_STR(ver)))) \
> +	type name ## _v ## ver args;					\
> +	type name ## _v ## ver args

And again here with "type name ## _v ## ver args" - is this duplication
intentional and safe?

The original asm-based macros also had this pattern, but were those
actually functioning correctly? The __rte_used attribute in the original
suggests these were declarations, not duplicate definitions.

> +#else /* !__has_attribute(symver) */
> +
> +/* Use asm tag to create symbol table entry */
>  #define RTE_VERSION_SYMBOL(ver, type, name, args) VERSIONING_WARN \
>  __asm__(".symver " RTE_STR(name) "_v" RTE_STR(ver) ", " RTE_STR(name) "@DPDK_" RTE_STR(ver)); \
>  __rte_used type name ## _v ## ver args; \
>  type name ## _v ## ver args

The fallback path retains __rte_used on the first declaration but the
new symver attribute path does not. Should __rte_used be retained in the
new macros to ensure unused versioned symbols are not optimized away?


More information about the test-report mailing list