It seems that most 32 bit applications will run on 64 bit linux assuming all the 32 bit libraries are present. But it seems to me there could be issues with architecture-dependent functions, and here I'm thinking of signals and setjmp/longjmp. I'm wondering if someone with greater experience could comment on what functions (if any) would cause a 32 bit app to be incompatible with a 64 bit OS.
+3
A:
The biggest issue for 32-bit applications running on 64-bit systems would be where programers mistakenly make assumptions about integer or pointer lengths and subsequently do non-portable things with them. There's a pretty good overview of the issues for C/C++ programmers to consider in this article by Sun
bjg
2010-07-01 18:42:15
I've seen many, many projects, that when compiled for x64 generate hundreds if not thousands of warning just because of this issue. And that includes recent projects so no excuses like 'yeah but back then there wasn't 64bit'
stijn
2010-07-01 18:49:36
These are issues when you want to recompile a 32 bit application for 64 bit architecture. But I'm asking about an application already compiled with a 32-bit compiler. The compiler has certainly already made assumptions about pointer sizes! So as I understand it it's up to the 64-bit OS to treat a 32-bit application appropriately.
c-urchin
2010-07-01 18:50:01
You're right. Of course when legacy 32bit applications were written they would not have known they might be running on 64-bit systems later. The 64-bit OS by way of its linker/loader (e.g. ld.so or ld.linux.so) has to remap addresses into its 64-bit process address space to make it run properly. Provided the 32-bit application is well written (as per the article) then everything should proceed.
bjg
2010-07-01 19:02:29
@bjg: The loader is aware of the 32bit executable, but simply falls back to loading with 4 byte addresses in a smaller space. The CPU and kernel handle all of the magic (instruction emulation, page faults, syscalls).
Yann Ramin
2010-07-01 19:05:05
@theatrus Admittedly my experience was with Solaris on SPARC which did things a certain way. I can't speak for how other architectures work this out.
bjg
2010-07-01 19:25:48
+6
A:
Even setjmp and longjmp should work correctly. There are no particular issues, from a user space application, which would present any issues. The actual 32bit emulation is done by the processor. System calls are the interface back to the 64bit kernel, which Linux correctly handles.
If the application was evil, and sent executable code to another 64bit process to execute, then various things would break.
Yann Ramin
2010-07-01 18:58:52
+1
A:
If Linux is compiled without 32bit legacy support your 32bit program won't function very well.
Noah Roberts
2010-07-01 19:04:31
As I said, assuming all the 32 bit libraries are present, which kind of implies that the kernel was also built with 32 bit support :-)
c-urchin
2010-07-01 19:11:28
A:
Let's take an example of 32 bit application which has a main module and loads a 32 bit dependent dll. If you are migrating both the main module as well as the 32 bit dependent dll, the application works fine on a 64 bit machine. But in case if you migrate only the main module, it will not be able to load 64 bit dependent dll from the 64 bit machine even if present. The reasons being -
Different alignment in memory of the data
Differences in the data type size
Please refer:
http://dev-faqs.blogspot.com/2008/03/accessing-32-bit-dlls-from-64-bit-code_02.html
Probably this is what you are looking for !
Devil Jin
2010-07-01 19:53:40
+1
A:
There really only two issues that arise with running 32 bit applications under 64 bit Linux, assuming you have the necessary 32 bit libraries:
Some
ioctl()s for lesser-used drivers do not work correctly when used by a 32 bit user process on a 64 bit kernel;Applications that have hardcoded
/usr/liband/or/libpaths to search for dynamic libraries won't work if the 32 bit libraries are located elsewhere.
caf
2010-07-04 23:02:43