Re: [dpdk-dev] RFC enabling dll/dso for dpdk on windows

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Jul 09, 2021 at 01:34:06PM +0200, Thomas Monjalon wrote:
> 09/07/2021 02:16, Tyler Retzlaff:
> > On Thu, Jul 08, 2021 at 10:39:13PM +0200, Thomas Monjalon wrote:
> > > 08/07/2021 21:21, Tyler Retzlaff:
> > > > (2) importing exported data symbols from a dll/dso on windows requires
> > > >     that the symbol be decorated with dllimport. optionally loading
> > > >     performance of dll/dso is also further improved by decorating
> > > >     exported function symbols. [3]
> > > > 
> > > > for (2) we would propose the introduction and use of two macros to
> > > > allow decoration of exported data symbols. these macro would be or
> > > > similarly named __rte_import and __rte_export. of note
> > > 
> > > That's the same symbol declared in a single place
> > > which is exported and imported.
> > > So I don't understand the need for 2 macros.
> > 
> > i may be misinterpreting your reply. you're saying there is no need for
> > 2 because we use .def files?
> > 
> > strictly speaking when exporting C symbols this is true. so yes, we
> > could introduce only __rte_import and not bother with __rte_export.
> > 
> > is that what you meant?
> > 
> > i don't have any objection to just __rte_import alone but it is
> > mandatory for data symbols.
> 
> It may be my misunderstanding.
> The function is declared only once in the .h
> so I don't understand where these 2 macros are used.
> 

okay, i think the question is about mechanically where they are used and
i'll limit my answer to data symbols since that's what we need them for.

the export is typically used at the point of definition and the import
at declaration. so ignoring anything about tls the following example
hopefully illustrates.

let's start with a module i'll just call it eal.dll it is declaring a
data symbol that will be exported and may be referenced internally within
eal.dll itself but also externally by other modules outside of eal.dll.

    // eal.c
    __rte_export
    int eal_some_var;

    // eal.h
    #ifndef BUILDING_EAL
    __rte_import
    #endif
    extern int eal_some_var;

    // eal_other.c
    #define BUILDING_EAL
    #include <eal.h>

    eal_some_var = 100;

we also have another module app.exe that consumes the variable
exported from eal.dll.

    // app.c
    #include <eal.h>

    eal_some_var = 200;

as mentioned in my first reply you can get away with not using
__rte_export because dpdk also lists the exports in the .map/.def files
even for data symbols but it is required for import [1]. the relevant
text from the documentation is quoted here.

    Using __declspec(dllimport) is optional on function declarations,
    but the compiler produces more efficient code if you use this
    keyword.  However, you must use __declspec(dllimport) for the
    importing executable to access the DLL's public data symbols and
    objects. Note that the users of your DLL still need to link with
    an import library.

    specifically "you must use __declspec(dllimport) for the importing
    executable to access the DLL's public data symbols" is relevant.

the other internal/external conditional compile for BUILDING_EAL is
applied to avoid generating the code for the extra layer of indirection
mentioned here [2] when using the variable in the same module in which
it was defined.

1. https://docs.microsoft.com/en-us/cpp/build/importing-into-an-application-using-declspec-dllimport?view=msvc-160
2. https://docs.microsoft.com/en-us/cpp/build/importing-data-using-declspec-dllimport?view=msvc-160