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

[David Marchand <david.marchand@redhat.com>]

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é?


-- 
David Marchand