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
PS: Other cases about shared libraries constructor/destructor.
The easy ones.
Mac OS X:
And the others
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 <phhargrove_at_[hidden]> wrote:
> The priority appears to have been added in gcc 4.3.
> You'll note it is not described in
> 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).
> On Tue, Jul 15, 2014 at 4:52 PM, Joshua Ladd <jladd.mlnx_at_[hidden]> 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
>> *These attributes are not currently implemented for Objective-C."*
>> On Tue, Jul 15, 2014 at 5:20 PM, Paul Hargrove <phhargrove_at_[hidden]>
>>> On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r <howardp_at_[hidden]>
>>>> I don't think there's anything wrong with using ctor/dtors in shared
>>>> but one does need to make sure that in these functions there's no
>>>> 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 H. Hargrove PHHargrove_at_[hidden]
>>> 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
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
>> devel mailing list
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
> Paul H. Hargrove PHHargrove_at_[hidden]
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: