|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