Re: Mixing libraries for different architectures into a shared lib

[John Reiser <jreiser at bitwagon dot com>]

On 01/21/2012 05:37 PM, Erik Leunissen wrote:
> A variation on this theme (ELF format presumed):
> 
> Is it possible to link a 32-bit (i686) object file into a shared lib for a 64-bit (x86_64) target, which otherwise consists of code from 64-bit object files (x86_64)?

Help yourself:  try it!  _You_ can answer that question
in a few minutes of experimentation.

In straightforward usage it depends on whether multi-architecture
and cross-architecture capabilities are implemented in your static binder.
Such as: when creating a specific single output format, does ld support
the union of all relocation types that are present in the various
formats of all input files?  [Probably not.]

Even if the answer should turn out to be "No, not in the general case",
it is possible to load any byte string by using the input format:
"binary".  See "objdump -i", and search for "-b INPUT-FORMAT" in
"info ld".  Symbol definition, relocation, etc., require extra
gymnastics for "binary" input format; but it is easy to insert
any known string of numeric bytes.

> Will it load (on a x86_64 architecture)?

For any program invocation such as execve(), the operating system
decides what to do based on ElfXX_Hdr.e_machine, .e_version, .e_flags, etc.
So, the first part of the answer depends on the operating system.
After that, some part of the runtime system that supports the
programming language environment [such as glibc for the C language,
in many cases] is responsible for supervising shared libraries.
In most cases this supervisor insists on the same .e_machine
(and other .e_* characteristics) as the main program.

> Will it run when loaded (likewise)?

The CPU will decode and execute the instruction stream
according to the current processor mode.  The operating
system initially sets the processor mode depending on
ElfXX_Hdr.  Similarly, only the operating system can change
the processor mode.  Also, x86_64 hardware does not permit
some specific changes.  For instance, x86_64 does not support
changing from long mode (64-bit) to vm86 mode (16-bit).
So, consult your operating system.

--