08/12/2020 08:03, Narcisa Ana Maria Vasile: > Hi, > > While using the DPDK libs as DLLs, I've ran into some access violation > errors. I believe they are caused by some incorrect imports. > In Windows, accessing an imported variable is done either by using > __declspec(dllimport), or by using an extra level of indirection[1].
Why coding on Windows is so complex? > Some examples of variables in DPDK that are not declared correctly: > rte_cycles.h: extern void (*rte_delay_us)(unsigned int us); > rte_mempool.h: extern struct rte_mempool_ops_table rte_mempool_ops_table; > rte_lcore.h: RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); (Which expands to > extern __thread unsigned per_lcore__lcore_id) > > To fix this, we need to add the __declspec(dllimport) keyword to the > declarations of these symbols. Also, we need to consider that the symbols can > be used both internally(in the same module) and externally (imported by other > modules). > We can define a macro that will tell if the symbol is used internally or is > imported by a different DLL. Example: > > #ifdef RTE_INTERNAL > extern void (*rte_delay_us)(unsigned int us); > #else > __declspec(dllimport) void (*rte_delay_us)(unsigned int us); > #endif > > We can then hide the Windows-specific keywords under a new macro, such as: > #define RTE_IMPORT __declspec(dllimport) > > However, there are a few issues to consider: > * We cannot add __declspec(dllimport) when declaring per_lcore__lcore_id for > example. We cannot have both __thread and __declspec(dllimport) (can't > import thread local variables). We cannot export a TLS variable? It looks to be a serious issue. > Have you discussed/run into these issues before? Let me know what you think. Curiously it has never been discussed in 2 years of DPDK porting to Windows. Thanks for raising.
