This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

coping with PT_PHDR not being in loaded segment


I think I agree with Ian's analysis here.  The current libc (elf/dl-load.c)
still behaves the way he described for 2.0.7.  If the phdr is not visible
in the loaded image, then I think we should make a malloc'd copy to save in
the l_phdr pointer.  The code already alloca's a copy for its own use in
this case, it just doesn't save a copy for later.



   Date: Thu, 06 May 1999 20:42:53 +0200
   From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>

   Btw, have you ever looked at the patch in 
   http://sourceware.cygnus.com/ml/gas2/1999/msg00041.html ? Is it the correct 
   fix for the make check FAIL on powerpc-linux-gnu?

No, I don't think it is.  I think this is a problem in the glibc
dynamic linker.  (I looked at glibc 2.0.7; I don't know about other
versions.)

The GNU linker does not ordinarily create a PT_PHDR program segment
for a shared library.  This follows the lead of the Solaris linker.

When the glibc 2.0.7 dynamic linker does not find a PT_PHDR program
segment, it assumes that the program headers may be found at the start
of the first PT_LOAD segment.  However, ELF does not require this.
The comment in the glibc sources (in dl-load.c) says this:

	/* There was no PT_PHDR specified.  We need to find the phdr in the
           load image ourselves.  We assume it is in fact in the load image
           somewhere, and that the first load command starts at the
           beginning of the file and thus contains the ELF file header.  */

However, I believe the dynamic linker should be able to operate
without having the program headers in the load segment at all.

What your patch changes is whether the linker puts the program headers
at the start of the first PT_LOAD segment.  Without your patch, the
linker does not put the program headers in loadable memory.  With your
patch, it does.

Since with the current script the program headers are not loaded, the
dynamic linker will wind up looking at nonsensical memory for the
program headers, and it will fail.  However, the dynamic linker does
know how to find the correct program headers by reading the file.
However, after reading the program headers, it throws them away, and
uses the copy which it expects to find in the file.  If there is no
PT_PHDR segment, it should instead keep and use its own copy.

Ian



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]