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

[Ian Lance Taylor <ian at wasabisystems dot com>]

Anthony Heading <aheading@jpmorgan.com> writes:

> In http://www.codesourcery.com/cxx-abi/cxx-closed.html#B7, the question
> of how to support C++ objects in shared memory is resolved by requiring
> "to force the objects, Vtables, functions, etc. to the same addresses
> in the various processes involved."
> 
> How could this be done with g++ and binutils (specifically on Linux
> or Solaris if that is relevant)?  Is it necessary only to ensure
> that a common shared library is mapped into memory at the same location
> in each process? Or is it more complex than that?

If you can arrange for all objects which are to be placed into shared
memory to have vtables which refer to the common shared library, then
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, and indeed
if your Linux kernel uses exec-shield-randomize, then the kernel is
likely to cause the address to be different in each process which uses
the shared library.

You can obviously mmap to a specific address, but dlopen doesn't take
a mapping, it takes a file name.  So I don't think that helps you.

With my binutils bias I would tend to follow a different approach.  If
you can identify the vtable code clearly enough to put it into a
common shared library, then you can identify it clearly enough to
describe it in a linker script.  Use a linker script to put all the
relevant code at a specific address (you will need to use PHDRS to
declare a new segment).  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.  The
main drawback I see to this approach is that I see no way to check the
condition at link time, so if you make a mistake and put an object
into shared memory which doesn't have the right vtable pointer you are
likely to wind up with a mystifying crash.

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

Would you mind either getting rid of this disclaimer, or posting from
a free e-mail account such as Yahoo or Google?  Thanks.  At least this
disclaimer does not declare your message to be top secret.

Ian