Bug 164097 - dlmopen namespace vs. debug, dl_iterate_phdr, introspection
Summary: dlmopen namespace vs. debug, dl_iterate_phdr, introspection
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-24 22:53 UTC by John Reiser
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-25 19:44:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Reiser 2005-07-24 22:53:15 UTC
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):

How reproducible:

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

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:

Comment 1 Jakub Jelinek 2005-07-25 06:50:07 UTC
1. I'd say patches for documentation are certainly welcome.
2. There is no such thing as the "current namespace".  There are simply one
   or more namespaces in the program and the namespaces can be uniquely
   identified either by a code address in one of the loaded libraries,
   perhaps also by the handle of one of the libraries (whatever cookie
   is returned from dlopen/dlmopen).  RETURN_ADDRESS (0) is used in several
   routines for ages (e.g. dlinfo).
3. None AFAIK.

I don't understand your comments regarding glibc version, both dlmopen and
dl_iterate_phdr are old interfaces (2.3.4+ resp. 2.2.5+), so it has nothing with
2.4 release or development towards it.

Comment 2 Ulrich Drepper 2005-07-25 19:44:58 UTC
There are no bugs.  Red hat just includes upstream code.  If you have changes to
propose, bring this up upstream.  (And I can tell you, I'll ignore anything
there unless these are concrete changes).  You certainly have absolutely no
right to be consulted in any decision making process as far as RH is concerned.

Note You need to log in before you can comment on or make changes to this bug.