Bug 78937 - dl_iterate_phdr belongs in ld-linux.so.2, not in libc.so.6
dl_iterate_phdr belongs in ld-linux.so.2, not in libc.so.6
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-03 14:47 EST by John Reiser
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-05 12:23:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2002-12-03 14:47:14 EST
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 ld-linux.so.2 (instead of in libc.so.6) 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:
Always

Steps to Reproduce:
1. cd /lib
2. nm -Dgop ld-linux.so.2 libc.so.6  |  grep dl_iterate_phdr
3.
	

Actual Results:  libc.so.6:0010c650 W dl_iterate_phdr

which shows that dl_iterate_phdr is in libc.so.6 and not in ld-linux.so.2

Expected Results:  ld-linux.so.2:XXXXXXXX T dl_iterate_phdr

showing that dl_iterate_phdr is in ld-linux.so.2

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 09:24:20 EST
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 libc.so
is already loaded and thus dl_iterate_phdr can be called.
dl_iterate_phdr cannot be really moved out of libc.so 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 12:23:01 EST
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
libc.so.6 is involved, and especially if libc.so.6 is _not_ involved.  The only
module that knows the layout of struct link_map, and is guaranteed to be
involved, is ld-linux.so.2 itself.  ld-linux.so.2 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
ld-linux.so.2 and libc.so.6.

"... 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 12:29:53 EST
There is a Solaris like ld.so auditing API planned, so really this won't be
reconsidered.

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 ld.so will
complain loudly.

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