Experimental Physics and
Industrial Control System

"Akeroyd, Freddie \(STFC, RAL, ISIS\) via Core-talk" <core-talk at aps.anl.gov> · Thu, 4 Feb 2021 21:45:37 +0000

Hi,

There are some options, but it might get a bit messy as they require using a .DEF file. You can hide the symbol name from the DLL export list by exporting symbols by ordinal rather than by name from the DLL (NONAME in .DEF), but if you wish to stop people being able to link to symbols by name via the .LIB import library then you also need to use PRIVATE in the .DEF; at that point I think only GetProcAddress() on the DLL specifying the ordinal is possible. As you can create a .LIB import library directly from a .DEF file, I think you could create the normal .LIB via linking with a .DEF with all testing functions marked PRIVATE and then create a separate .LIB for linking tests that uses a .DEF based on this one but with all the PRIVATE keywords removed. You may be able to automate creating a .DEF if you did a normal epics dllexport link, created a def file from the resulting .LIB, added PRIVATE to items with e.g a "Test" prefix, and then relinked the DLL using this .DEF so the Test functions are only visible as ordinals. But I've never tried doing all this myself...

https://docs.microsoft.com/en-us/cpp/build/exporting-functions-from-a-dll-by-ordinal-rather-than-by-name?view=msvc-160

https://docs.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-160

Regards,

Freddie

> -----Original Message-----
> From: Core-talk <core-talk-bounces at aps.anl.gov> On Behalf Of Michael
> Davidsaver via Core-talk
> Sent: 27 January 2021 14:05
> To: Ralph Lange <ralph.lange at gmx.de>
> Cc: EPICS Core Talk <core-talk at aps.anl.gov>
> Subject: Re: Unit tests on Windows DLL internals
> 
> On 1/27/21 3:01 AM, Ralph Lange via Core-talk wrote:
> > Question about developing on Windows:
> >
> > How do you manage unit testing of internal classes in DLLs?
> >
> > Internal classes (that are not DLL exported) are by design not visible through
> the DLL interface, which means linking a unit test against the DLL won't allow it
> to access the internal APIs it is supposed to test.
> > (No such problem on Linux where all functions inside the shared
> > library are visible.)
> >
> > I know I can work around by linking the needed objects directly into the test
> executable. Is there any preferable or better solution?
> 
> I'm in the habit of marking these sorts of symbols for export.
> In my mind dllexport does not imply a public API.  eg. about half of the symbols
> exported by libca.so are only used by libdbCore.so (for local CA).
> 
> 
> 
> On 1/27/21 3:57 AM, Mark Rivers via Core-talk wrote:
> ...
> > That is true by default, but GCC >= 4 has __attribute__ ((visibility ("hidden")))
> which will also hide classes on Linux.
> >
> > This article makes the argument for why it is a good idea to use it:
> >
> > https://gcc.gnu.org/wiki/Visibility
> 
> I keep the following in configure/CONFIG_SITE.local
> 
> USR_CFLAGS_Linux += -fvisibility=hidden
> USR_CXXFLAGS_Linux += -fvisibility=hidden -fvisibility-inlines-hidden
> 
> 
> Mostly this helps me find dllimport/export problems earlier, though there is
> also some slight reduction in linking/loading time.
> (I'll take what I can get wrt. c++ build times)

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System