Enforcing the portability of this sounds like a huge [almost impossible] mess, without a clean portable solution (more about this below). However, few things should be considered: - Except for reinit, Open MPI works without it! If we provide such a capability it will be more a convenience capability to keep valgrind happy, than a necessity - in case the constructor/destructor functionality is available we explicitly control the ordering in which the shared libraries are opened/closed as we control the dl_open/dl_close for most of the shared libraries.
George. PS: Other cases about shared libraries constructor/destructor. The easy ones. Mac OS X: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html Solaris: http://docs.oracle.com/cd/E18659_01/html/821-1383/bkamq.html And the others PGI: http://www.pgroup.com/userforum/viewtopic.php?t=697&sid=4efce7bfb4e914e42f48f219fc7e6a7e XLC: beg for forgiveness (there is a -binitifini function but it must be specified at link time) On Tue, Jul 15, 2014 at 8:06 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > The priority appears to have been added in gcc 4.3. > You'll note it is not described in > https://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Function-Attributes.html > > I also don't think the presence of the priority argument fixes anything... > > An OpenMPI code author cannot change the "priority" of a ctor or dtor in a > precompiled third-party library (libpmi comes to mind). Nor can one know > what value the third part chose (in order to be higher or lower than > theirs). You cannot even be assured the third-party didn't set priority to > INT_MIN or INT_MAX (or whatever). > > That text also says nothing about dl_open() and dl_close() which must be > considered in Open MPI. > > Before assuming constructor/destructor attributes are going to save the > world, wash your dog, and pick up the dry cleaning, one should probably > verify some minimal level of support on non-gnu tool-chains including > vendor compilers (PGI, XLC, etc) and system linkers (Darwin and Solaris). > > -Paul > > > On Tue, Jul 15, 2014 at 4:52 PM, Joshua Ladd <jladd.m...@gmail.com> wrote: > >> According to http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html >> >> *"constructor * >> * destructor * >> * constructor (*priority*)** destructor (priority)* *The constructor >> attribute causes the function to be called automatically before execution >> enters main (). Similarly, the destructor attribute causes the function to >> be called automatically after main () completes or exit () is called. >> Functions with these attributes are useful for initializing data that is >> used implicitly during the execution of the program. * >> >> *You may provide an optional integer priority to control the order in >> which constructor and destructor functions are run. A constructor with a >> smaller priority number runs before a constructor with a larger priority >> number; the opposite relationship holds for destructors. So, if you have a >> constructor that allocates a resource and a destructor that deallocates the >> same resource, both functions typically have the same priority. The >> priorities for constructor and destructor functions are the same as those >> specified for namespace-scope C++ objects (see C++ Attributes >> <http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes>). >> * >> >> *These attributes are not currently implemented for Objective-C."* >> >> >> >> On Tue, Jul 15, 2014 at 5:20 PM, Paul Hargrove <phhargr...@lbl.gov> >> wrote: >> >>> >>> On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r <howa...@lanl.gov> >>> wrote: >>> >>>> I don't think there's anything wrong with using ctor/dtors in shared >>>> libraries, >>>> but one does need to make sure that in these functions there's no >>>> assumptions >>>> about ordering of them wrt to other ctors/dtors. >>>> >>> >>> The ELF specification is clear that the order of execution of DT_INIT >>> and DT_FINI entries is undefined. >>> The .ctors and .dtors sections typically used by the GNU toolchain are, >>> I believe, not part of any formal linker specification. >>> So, I agree w/ Howard that one must take care not to assume anything >>> about order. >>> >>> -Paul >>> >>> >>> -- >>> Paul H. Hargrove phhargr...@lbl.gov >>> Future Technologies Group >>> Computer and Data Sciences Department Tel: +1-510-495-2352 >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/07/15153.php >>> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/07/15155.php >> > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15156.php >
