This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Mixing libraries for different architectures into a shared lib
On 22/01/12 06:01, John Reiser wrote:
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.
You're right. Sorry.
I tried it, and I succeeded in producing a shared lib (x86_64 target)
from several 64-bit object files (x86_64 target) and one 32-bit object
file (i686 target), using gcc -shared -m64 ...
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.
OK, thank for pointing this out.
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.
Oh, it's linux (OpenSuSE 11.4).
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.
I'm completely unfamiliar with .e_* characteristics. I found it to
relate to the ELF header, which is also unknown terrain. Will do some
exploration.
In my case, yes, the programming language is C with a few source files
containing inline assembly. And here you've touched the practical reason
for my question:
One of the C-source files contains inline assembly, 32-bit only, i.e.
compiling for x86_64 will fail. Since I can't program assembly, I was
wondering whether I could work around the problem by producing an i686
object file for only this specific translation unit. While compiling the
rest for x86_64 and still be able to produce a usable shared lib for a
x86_64 linux multilib system.
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.
With respect to processor modes: I'm unfamiliar with the term. In my
case, does it mean whether the processor can switch from executing
64-bit instructions to 32-bit instructions? The following depends on my
correct interpretation of this (I'd appreciate a check on my logic here):
My case concerns only x86_64 processors running a linux or windows OS
for 64-bit. I recall that all x86_64 processors have been designed to be
able to execute 32-bit code; so I think that covers the hardware part of
the equation. About the OS: personally I'm working on an Intel Core2,
and it executes 32-bit programs fine under linux (OpenSuSE 11.4 x86_64
multilib) and MS Windows 7 and Vista. With the possible exception of
Windows XP, I'm having evidence that all linux and MS Windows OS's that
pertain to 64-bit will do their job properly in this respect.
Does this reasoning make sense with respect to "processor modes"?
If so, there is hope.
One point remains: the matter with .e_* characteristics. Right now, this
subject is one chunk of unexplored terrain. I'm going to have a go.
Thanks a lot for your information,
Erik.