Re: [RFC v4 5/8] build: generate symbol maps

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 17 Mar 2025 16:43:01 +0100
David Marchand <david.marchand@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@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.