This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: how to force C++ objects to an address? (ABI issue B-7)


On Tue, Apr 20, 2004 at 02:21:48AM -0400, Ian Lance Taylor wrote:
> Anthony Heading <aheading@jpmorgan.com> writes:
> 
> > Clutching at straws, if a .so file was already mmap'd into a processes
> > address space, is there any chance that a subsequent dlopen would
> > decide to use that existing copy?  (Hmm - that sounds a bit unlikely)
> 
> That sounds pretty tough to me.  The dynamic linker has to apply the
> dynamic relocations when dlopen is called on a shared library.  If a
> the library is already mapped into memory, dlopen would have to start
> modifying it.  That would seem to violate natural expectations of how
> mmap should work.
> 
> > Alternatively, if one were to think about changing Linux to support
> > this - e.g. creating a variant on dlopen that took an address, or
> > maybe better using the (unused?) physical address field in the
> > program headers to indicate where a library should be loaded, or
> > perhaps less intrusively an extra section to supply that information,
> > is it realistic to hope this might be acceptable for the wider world?
> 
> It seems like a reasonable extension to me.  I think the natural
> approach would be a new version of dlopen.  Using the physical address
> field doesn't sound right to me.  Adding a new program header type to
> carry the required address ought to work, and would be useful since it
> wouldn't require dlopen.  The place to change would be elf/dl-load.c
> in glibc.

Why do you need any new program header types?
If a shared library has non-zero base VMA (first PT_LOAD segment's p_vaddr),
ld.so will attempt to mmap at that address and only use different address
if that range was already occupied by something else.
Current glibc behavior is:
1) if binary is not position independent executable (PIE) and
   LD_USE_LOAD_BIAS is not set in the environment, p_vaddr will be honored
   if mmap succeeds
2) if binary is PIE and LD_USE_LOAD_BIAS is not set in the environment, p_vaddr
   will not be honored
3) if LD_USE_LOAD_BIAS=1 is in the environment, p_vaddr will be honored
4) if LD_USE_LOAD_BIAS=0 is in the environment, p_vaddr will not be honored

But, the problem is that if you want to share the same memory image between
several programs, you must ensure that all relocations in that shared
library must resolve to the same addresses, i.e. also all libraries that
shared library ever uses (including unintentional symbol interposition)
must have the same load addresses.

	Jakub


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