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

[Andre Muezerie <andremue@linux.microsoft.com>]

On Wed, Mar 19, 2025 at 06:12:37PM +0100, David Marchand wrote:
> On Wed, Mar 19, 2025 at 5:19 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > 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.
> 
> This could be interesting, though it is a step further the current series.
> 
> 
> - For clang, I would expect -fvisibility is supported.
> 
> - There is one warning I am not too fond of, in gcc manual:
>            Be aware that headers from outside your project, in
> particular system headers and headers from any other library you use,
> may not be expecting to be compiled with visibility other than the
> default.  You may need to explicitly
>            say "#pragma GCC visibility push(default)" before including
> any such headers.
> 
> I also see that this requires annotating symbol at the declaration level.
> That would require to parse headers instead of sources (which seems
> more appropriate as we are talking about symbol exports).
> 
> I have some doubt though wrt base driver code, that we are not
> supposed to update...
> The current RTE_EXPORT_* macros of this series were not doing anything
> to the symbol themselves, and could be located anywhere as long as
> meson could parse them.
> 
> 
> - Not sure what the default for MSVC is, André?
> 

My understanding is that "-fvisiblity=hidden" only has effect on dynamic linking.
For static linking a similar goal can be achieved with ld's option --exclude-libs
(https://sourceware.org/binutils/docs/ld/Options.html).

The default for msvc is hidden. Only functions that are explicitly exported
with __declspec(dllexport) modifier or through a .def file are visible externally.

It seems this matches exactly the behavior you would get by using -fvisiblity=hidden
with gcc/clang.
--
Andre Muezerie

> 
> -- 
> David Marchand