On Wed, Mar 19, 2025 at 06:12:37PM +0100, David Marchand wrote: > On Wed, Mar 19, 2025 at 5:19 PM Stephen Hemminger > <step...@networkplumber.org> wrote: > > > > On Mon, 17 Mar 2025 16:43:01 +0100 > > David Marchand <david.march...@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.march...@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
