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

Anthony Heading aheading@jpmorgan.com
Tue Apr 20 02:28:00 GMT 2004


(sending again, since this seemed to get caught in a spam trap...)

On Tue, Apr 20, 2004 at 08:52:15AM +0900, Anthony Heading wrote:
> On Mon, Apr 19, 2004 at 04:26:03PM -0400, Ian Lance Taylor wrote:
> > [under some constraints...]
> > I think that having each relevant process map the shared library to
> > the same virtual address would indeed suffice.
> > 
> > Unfortunately, I'm not aware of any way to guarantee that.  The
> > dynamic linker does not guarantee any particular address, [...]
> > 
> > Use that same linker script when linking all
> > relevant binaries.  Then you can know that all vtable references in
> > shared memory will refer to the same address in all processes.
> 
> Thanks first of all for the pointer to the right overall direction.
> 
> I'm slightly confused as to how this should work.  The idea
> is to create a new segment where we specify a particular virtual
> address in the relevant program header?  If the dynamic
> loader will use that, why would it not do so for the ordinary
> segment that contains the '.text' section etc?  I'm not
> quite understanding how moving anything to a custom segment
> evades the point you made that the dynamic linker 'does not
> guarantee any particular address'.
> 
> > Would you mind either getting rid of this disclaimer, or [...]
> 
> Sorry - yes, I should make an effort not to use the work email
> gateway for that reason.  Won't do so right now though to avoid
> breaking the thread...
> 
> 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.




More information about the Binutils mailing list