[RFC v4 5/8] build: generate symbol maps
Stephen Hemminger
stephen at networkplumber.org
Wed Mar 19 17:19:12 CET 2025
On Mon, 17 Mar 2025 16:43:01 +0100
David Marchand <david.marchand at redhat.com> wrote:
> Rather than maintain a file in parallel of the code, symbols to be
> exported can be marked with a token RTE_EXPORT_*SYMBOL.
>
> From those marks, the build framework generates map files only for
> symbols actually compiled (which means that the WINDOWS_NO_EXPORT hack
> becomes unnecessary).
>
> The build framework directly creates a map file in the format that the
> linker expects (rather than converting from GNU linker to MSVC linker).
>
> Empty maps are allowed again as a replacement for drivers/version.map.
>
> The symbol check is updated to only support the new format.
>
> Signed-off-by: David Marchand <david.marchand at redhat.com>
> ---
> Changes since RFC v3:
> - polished python,
> - fixed doc updates not belonging to this patch,
> - renamed map files,
> - changed msvc->mslinker as link mode,
> - added parsing of AVX sources,
>
> Changes since RFC v2:
> - because of MSVC limitations wrt macro passed via cmdline,
> used an internal header for defining RTE_EXPORT_* macros,
> - updated documentation and tooling,
Looks like a good idea.
Is there any way to make symbols in drivers local by default?
Right now if a driver defines a non-static function it will
be visible in other code when DPDK application is statically linked.
This can lead to problems where exports are missing or accidental
name conflicts. Gcc has -fvisiblity=hidden not sure about others.
More information about the dev
mailing list