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 08:52:54AM +0200, Jakub Jelinek wrote:
> 3) if LD_USE_LOAD_BIAS=1 is in the environment, p_vaddr will be honored

Aha. That's a newer option than my documentation includes. Thanks.

BTW the C++ ABI mentions that "the base psABI defines a flag, EF_IA_64_ABSOLUTE,
which forces an executable object to the addresses specified in ELF".  Is
this being used by glibc at all?  How does it interact with these
prelink/load-bias controls?

> 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.

Umm, don't follow.  To allow C++ objects to be stored in shared memory,
we're not looking to share the memory image of the shared library.  Doesn't
one just need to ensure that the function addresses referenced _directly_
by the vtable (and pointers to const strings and so on) are fixed?  And
presumably the vtable itself, which means I guess the data segment
needs to be at a fixed address too.  But it shouldn't matter
if downstream relocations are all to different places, as long as
each process is internally self-consistent..

i.e. I'm thinking now this Linux prelinking support gives everything that's
needed to allow objects in shared memory.  Does that seem right?

Thanks!

Anthony

============



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data 
and other information are not warranted as to completeness or accuracy and 
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.



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