Subject: Re: ELF prebinding round 2: shared object prerelocation
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Bang Jun-Young <junyoung@mogua.com>
List: tech-userlevel
Date: 09/22/2002 11:59:00
On Sat, Sep 21, 2002 at 06:52:54PM -0700, Jason R Thorpe wrote:
> On Sat, Sep 21, 2002 at 04:21:10PM +0900, Bang Jun-Young wrote:
> 
>  > A shared object now has preferred base address, which gives a hint
>  > to ld.elf_so where to load the object. This information must be known
>  > to ld.elf_so before shared object is actually loaded, so I decided to 
>  > put it in p_paddr of the first PT_LOAD entry. This field has unspecifed
>  > contents and is ignored, according to SysV ABI spec (in normal case
>  > p_paddr == p_vaddr).
> 
> Hm.  This seems like ... not the best way.  The problem is that
> the preferred address could be very different based on the program
> that uses the lib, not the lib itself.

If you run prebind with -s option, you'll be able to know what I'm trying
to implement. ;-) Every system shared library has its own preferred
base address, so it's guaranted that libraries don't overlap each other. 

> 
> ...but, ignoring that part... :-)
> 
> I'm not particularly keen on the idea of using the "paddr" in the first
> phdr to indicate the preferred address -- seems like it would be better
> to insert a new entry into .dynamic which contained the necessary info.

Two problems are arising:

(1) It may break ABI (as with NetBSD this wouldn't be a problem). I'm
    not sure what number is reserved for OS-specific use. Maybe between
    DT_LOPROC and DT_HIPROC? The ABI says they are reserved for processor
    specific semantics.

(2) prefbase must be known to ld.elf_so before object is actually loaded,
    that is, at the point where the first page of an object is read in.  
    .dynamic section usually comes after all PT_LOAD sections, so ld
    script should be modified so that .dynamic is placed just after Phdr
    (to fit in the first page of file). And executables should be rebuilt
    with new ld to take advantage of it.

Jun-Young

-- 
Bang Jun-Young <junyoung@mogua.com>