Document behavior of atexit() when called in a DSO that is later unloaded.

Would be nice to document when/where this originated (in glibc?) if
anyone knows...

tweaks by schwarze@
ok jmc@ espie@ kettenis@ schwarze@ dimitry(at)google.com

1 files changed, 14 insertions, 2 deletions

diff --git a/lib/libc/stdlib/atexit.3 b/lib/libc/stdlib/atexit.3
index 8e3ac3e60fa..c4f56c90fac 100644
--- a/lib/libc/stdlib/atexit.3
+++ b/lib/libc/stdlib/atexit.3
@@ -29,9 +29,9 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.\"	$OpenBSD: atexit.3,v 1.9 2013/06/05 03:39:23 tedu Exp $
+.\"	$OpenBSD: atexit.3,v 1.10 2014/11/20 04:55:43 guenther Exp $
 .\"
-.Dd $Mdocdate: June 5 2013 $
+.Dd $Mdocdate: November 20 2014 $
 .Dt ATEXIT 3
 .Os
 .Sh NAME
@@ -55,6 +55,15 @@ no arguments are passed.
 At least 32 functions can always be registered,
 and more are allowed as long as sufficient memory can be allocated.
 .Pp
+If a shared object is unloaded from process memory using
+.Xr dlclose 3 ,
+then any functions registered by calling
+.Fn atexit
+from that shared object will be called in reverse order and unregistered.
+Note that it is the source of the call to
+.Fn atexit
+that matters, not the source of the function that was registered.
+.Pp
 .Fn atexit
 is very difficult to use correctly without creating
 .Xr exit 3 Ns -time
@@ -75,3 +84,6 @@ The
 .Fn atexit
 function conforms to
 .St -ansiC .
+.Pp
+The behavior when a shared object is unloaded is an extension to
+that standard.