Mixing libraries for different architectures into a shared lib

[Erik Leunissen]

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.