This is the mail archive of the 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: 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,


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