Bug 164097

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
In glibc-2.3.90-5 the visible implementation of dynamic linking symbol namespaces (including dlmopen) appears to have properties that seem to create problems for debugging, use of dl_iterate_phdr, and introspection of the address space in general.  The version number "2.3.90" tends to indicate movement towards a release candidate for glibc-2.4, but where implementation may be incomplete.  So further development may change the state, but right now these are concerns.

1.  I could not find the documentation for design goals, features, and implementation of namespaces and dlmopen in the expected place manual/*.texi or any other place.  I have consulted the source files including dlfcn/dlmopen.c and elf/dl-*.c.  Where are other places to look?

2. The use of RETURN_ADDRESS (0) in __dlmopen() and __dl_iterate_phdr() makes it difficult for a debugger or introspecting subroutine to inquire or manage all namespaces and/or the full address space.  Consideration should be given to allowing another parameter to specify the namespace, using a namespace_self() function or a pronoun value (such as (Lmid_t)-1, perhaps) to specify the current namespace.  Also, RETURN_ADDRESS(0) might be in runtime-generated code which would not be part of any current namespace.

3. What is the exported user-callable function which enumerates the current existing namespaces?

4. It used to be true that the PT_PHDRs reported by dl_iterate_phdr() would cover all entry points to functions that were in loaded modules.  It seems that this no longer will be the case because dl_iterate_phdr apparently iterates only the current namespace, yet function pointers can be passed between namespaces.  So a legitimate "alien" instruction address may appear, one not covered by the PT_PHDRs reported by dl_iterate_phdr.  This makes debugging harder.

5.  The logic in __dl_iterate_phdr (line 56 of elf/dl-iteratephdr.c):
        if (caller >= (const void *) l->l_map_start
            && caller < (const void *) l->l_map_end)
          /* There must be exactly one DSO for the range of the virtual
             memory.  Otherwise something is really broken.  */
does not allow for the case of a module having three PT_LOAD with adjacent consecutive page ranges, which at runtime uses munmap() to remove the middle PT_LOAD.  This leaves a hole which the Linux kernel may decide to use as the page range for a later dlopen() [if ET_DYN and 0==.p_vaddr; or if the "overlay" module is pre-linked that way on purpose], which will result in the interval for the new module being nested inside the interval for the old module.

6. The relationship is unclear between multiple namespaces and the doubly-linked list link_map.l_next and .l_prev of loaded modules.  Is there a separate list for each namespace, or just one list per process, or ...?

7. The use of struct link_map.l_removed seems to be ignored by dl_iterate_phdr, and it looks like a removed module may still be reported by the iteration.  The location of .l_removed in the "private" part of struct link_map seems to cause problems for debuggers and others who use .l_next and .l_prev to observe the current state.


Version-Release number of selected component (if applicable):
glibc-2.3.90-5

How reproducible:
Always

Steps to Reproduce:
1. Examine glibc-2.3.90-5 manual/*.texi, dlfcn/dlmopen.c, and elf/dl-*.c.
2.
3.
  

Actual Results:  Concerns raised as in Description.

Expected Results:  Documentation explaining goals, features, and implementation of namespaces.  Discussion of changed properties (with respect to modules, symbols, and address space) for debugger, introspection, callers of dl_iterate_phdr.  

Additional info: