Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal
From: George Bosilca (bosilca_at_[hidden])
Date: 2014-07-15 20:48:25


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 <phhargrove_at_[hidden]> 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.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
>> <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 <phhargrove_at_[hidden]>
>> wrote:
>>
>>>
>>> On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r <howardp_at_[hidden]>
>>> 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 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
>>> devel_at_[hidden]
>>> 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
>> devel_at_[hidden]
>> 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 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
> devel_at_[hidden]
> 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
>