Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 78937 - dl_iterate_phdr belongs in, not in
Summary: dl_iterate_phdr belongs in, not in
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-03 19:47 UTC by John Reiser
Modified: 2016-11-24 15:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-05 17:23:12 UTC

Attachments (Terms of Use)

Description John Reiser 2002-12-03 19:47:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
The routine dl_iterate_phdr() which is declared in <link.h> should be
implemented in the runtime loader (instead of in so
that programs and modules that do not use libc, or that are invoked before libc
is loaded and initialized, can still perform introspection on the Phdrs of
loaded modules.

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

How reproducible:

Steps to Reproduce:
1. cd /lib
2. nm -Dgop  |  grep dl_iterate_phdr

Actual Results: W dl_iterate_phdr

which shows that dl_iterate_phdr is in and not in

Expected Results: T dl_iterate_phdr

showing that dl_iterate_phdr is in

Additional info:

Because <link.h> hides all but a prefix of struct link_map, then access routines
such as dl_iterate_phdr() must be provided by the runtime loader itself.

Comment 1 Jakub Jelinek 2002-12-04 14:24:20 UTC
I wonder why programs which don't use libc need libc dynamic linker and don't
roll their own...
If a program uses libc, then at the time DSO constructors are run
is already loaded and thus dl_iterate_phdr can be called.
dl_iterate_phdr cannot be really moved out of because of symbol versioning
(which records the containing DSO).
Well, without libc/libdl you cannot use dlopen (because most of the _dl_*
routines are GLIBC_PRIVATE) either.

Comment 2 John Reiser 2002-12-05 17:23:01 UTC
Please reconsider.  The current setup does not provide adequate capability for
introspection of the loaded modules.  This is independent of libc/libdl in
general, and never needs dlopen in particular.

For instance, suppose that some code is auditing the loading and relocation of
modules, using r_debug.r_brk or similar.  Then it is reasonably necessary to be
able to run dl_iterate_phdr at any invocation of r_brk, regardless of whether is involved, and especially if is _not_ involved.  The only
module that knows the layout of struct link_map, and is guaranteed to be
involved, is itself. provides no clues about the
layout of struct link_map (except the first 5 members, which are insufficient to
run dl_iterate_phdr); dl_iterate_phdr is supposed to be the way to find out.
[Even so, it is still impossible to find the address of the Elf32_Ehdr, or the
value of .e_entry, .e_machine, .e_version, .e_ident[], etc.]

Because it has no need for stateful storage, dl_iterate_phdr could go into both and

"... symbol versioning (which records the containing DSO)" is not true [except
perhaps for pre-linking?]  Only the symbol name and the version are recorded;
the containing DSO at link time has no necessary connection with the resolving
DSO at runtime.  Otherwise LD_PRELOAD would not work, the organization of DSOs
could not be refactored after an application was linked, etc.

Comment 3 Jakub Jelinek 2002-12-05 17:29:53 UTC
There is a Solaris like auditing API planned, so really this won't be

And as for versioning, you're wrong.
SHT_GNU_verneed section really records what file which symbol was found during
linking (together with SHT_GNU_verdef). Of course you can interpose symbols,
but if a symbol from a versioned library simply disappears, then will
complain loudly.

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