nuttx/libs/libc/dlfcn/lib_dlclose.c

118 lines
4.9 KiB
C
Raw Normal View History

/****************************************************************************
* libs/libc/dlfcn/lib_dlclose.c
*
* SPDX-License-Identifier: Apache-2.0
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
/****************************************************************************
* Included Files
****************************************************************************/
#include <nuttx/config.h>
#include <dlfcn.h>
#include <nuttx/lib/elf.h>
/****************************************************************************
* Private Functions
****************************************************************************/
/****************************************************************************
* Public Functions
****************************************************************************/
/****************************************************************************
* Name: dlclose
*
* Description:
* dlclose() is used to inform the system that the object referenced by a
* handle returned from a previous dlopen() invocation is no longer needed
* by the application.
*
* The use of dlclose() reflects a statement of intent on the part of the
* process, but does not create any requirement upon the implementation,
* such as removal of the code or symbols referenced by handle. Once an
* object has been closed using dlclose() an application should assume
* that its symbols are no longer available to dlsym(). All objects loaded
* automatically as a result of invoking dlopen() on the referenced object
* are also closed.
*
* Although a dlclose() operation is not required to remove structures
* from an address space, neither is an implementation prohibited from
* doing so. The only restriction on such a removal is that no object will
* be removed to which references have been relocated, until or unless all
* such references are removed. For instance, an object that had been
* loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might
* provide a target for dynamic relocations performed in the processing of
* other objects - in such environments, an application may assume that no
* relocation, once made, will be undone or remade unless the object
* requiring the relocation has itself been removed.
*
* Input Parameters:
* handle - The opaque, non-NULL value returned by a previous successful
* call to dlopen().
*
* Returned Value:
* If the referenced object was successfully closed, dlclose() returns 0.
* If the object could not be closed, or if handle does not refer to an
* open object, dlclose() returns a non-zero value. More detailed
* diagnostic information will be available through dlerror().
*
* Reference: OpenGroup.org
*
****************************************************************************/
int dlclose(FAR void *handle)
{
#if defined(CONFIG_BUILD_FLAT) || defined(CONFIG_BUILD_PROTECTED)
libc/dlfcn: Count opens so a library can be shared. dlopen() of a library that is already loaded fails. libelf_insert() rejects a name that is already in the module registry with EEXIST, and dlinsert() passes that straight out, so the second caller gets NULL. POSIX says dlopen() shall return a handle to the object, and there is no way today for two modules to hold the same library at once -- which is what a shared library is for. So dlopen() now takes another reference on a library that is already there, and dlclose() only tears it down when the last handle goes. The count lives in the dlfcn layer rather than in libelf_insert() so that insmod keeps its own behaviour: a second insmod of the same name still fails with EEXIST, which is right for a kernel module. The module name is what makes any of this possible, and a PROTECTED build did not have one. Names were defined for CONFIG_BUILD_FLAT or the kernel side of a split build, on the reasoning that only the kernel needed them, which predates dlopen() being usable from user space. Without a name the user-space copy of libelf cannot recognise a second open of a library, cannot count opens, and cannot make dlclose() mean anything -- two dlopen()s there produce two independent copies of the library and lose track of the first. Names are therefore defined wherever CONFIG_LIBC_DLFCN is, which costs NAME_MAX per loaded module in that configuration. The path no longer has to be copied either. The module name is the basename of the file and libelf_insert() takes it as a const string, so dlinsert() finds it with strrchr() instead of handing a writable duplicate of the whole path to basename(). BUILD_KERNEL is deliberately untouched. dlopen() returns NULL there unconditionally: dlinsert() is a stub, because sharing a library between processes with separate address spaces needs the text in a shared region and the data per process at a matching virtual address, which is a different problem from this one. Built for mps3-an547:picostest with and without CONFIG_LIBC_DLFCN, and for stm32f4discovery:kostest, a PROTECTED configuration, with it enabled. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-03 12:05:40 +02:00
/* In the FLAT build, a shared library is essentially the same as a kernel
* module.
*
* The PROTECTED build is equivalent to the FLAT build EXCEPT that there
2017-01-29 07:52:44 -06:00
* must be two copies of the module logic: One residing in kernel
* space and using the kernel symbol table and one residing in user space
* using the user space symbol table.
*
* dlremove() is essentially a clone of rmmod().
*/
libc/dlfcn: Count opens so a library can be shared. dlopen() of a library that is already loaded fails. libelf_insert() rejects a name that is already in the module registry with EEXIST, and dlinsert() passes that straight out, so the second caller gets NULL. POSIX says dlopen() shall return a handle to the object, and there is no way today for two modules to hold the same library at once -- which is what a shared library is for. So dlopen() now takes another reference on a library that is already there, and dlclose() only tears it down when the last handle goes. The count lives in the dlfcn layer rather than in libelf_insert() so that insmod keeps its own behaviour: a second insmod of the same name still fails with EEXIST, which is right for a kernel module. The module name is what makes any of this possible, and a PROTECTED build did not have one. Names were defined for CONFIG_BUILD_FLAT or the kernel side of a split build, on the reasoning that only the kernel needed them, which predates dlopen() being usable from user space. Without a name the user-space copy of libelf cannot recognise a second open of a library, cannot count opens, and cannot make dlclose() mean anything -- two dlopen()s there produce two independent copies of the library and lose track of the first. Names are therefore defined wherever CONFIG_LIBC_DLFCN is, which costs NAME_MAX per loaded module in that configuration. The path no longer has to be copied either. The module name is the basename of the file and libelf_insert() takes it as a const string, so dlinsert() finds it with strrchr() instead of handing a writable duplicate of the whole path to basename(). BUILD_KERNEL is deliberately untouched. dlopen() returns NULL there unconditionally: dlinsert() is a stub, because sharing a library between processes with separate address spaces needs the text in a shared region and the data per process at a matching virtual address, which is a different problem from this one. Built for mps3-an547:picostest with and without CONFIG_LIBC_DLFCN, and for stm32f4discovery:kostest, a PROTECTED configuration, with it enabled. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
2026-08-03 12:05:40 +02:00
/* libelf_remove() gives back a reference and unloads only when the last
* one goes, so closing one of two handles leaves the other usable.
*/
return libelf_remove(handle);
#else /* if defined(CONFIG_BUILD_KERNEL) */
/* The KERNEL build is considerably more complex: In order to be shared,
* the .text portion of the module must be (1) build for PIC/PID operation
* and (2) must like in a shared memory region accessible from all
* processes. The .data/.bss portion of the module must be allocated in
* the user space of each process, but must lie at the same virtual address
* so that it can be referenced from the one copy of the text in the shared
* memory region.
*/
/* #warning Missing logic */
return -ENOSYS;
#endif
2017-01-29 07:52:44 -06:00
}