Geert Uytterhoeven writes: > On Thu, 30 Jan 2003, Albert D. Cahalan wrote:
>>>> This is kind of a survey for PowerPC Linux users. >>>> Is it OK to make 32-bit PowerPC apps bigger and >>>> slower to allow for running them on IBM's 64-bit >>>> hardware? This would hurt everyone running Linux >>>> on a Mac. >>> >>> 32 bit PowerPC Linux is not exclusive to the Mac. It is run >>> on PowerPC ATX boards too, which are nothing like a Mac. >> >> Yeah, I know, but that isn't the popular choice. >> I once had 32-bit PowerPC Linux running on the >> Force PowerCore 6750 VME and an even more exotic >> embedded supercomputer node. Never mind though... >> >> The point is, normal 32-bit systems are getting hurt >> because apps are being asked to support 64-bit kernels >> with the same binary. > > Ugh, the embedded PPC people will be happy > (and /me too with my old 604e)... > > Usually people try to fix their 64-bit kernel so they can run > _unmodified_ 32-bit applications. So in your case I would call > the applications '32/64-bit applications' instead of `32-bit > applications'. > > What is the exact nature of the changes you need to make > to the 32-bit applications? It's the "unmodified" part that is a problem. Things would be more tolerable if something like __32_on_64__ were defined by the compiler, allowing 64-bit systems to use separate executables from the 32-bit systems. Apps have to use "long long" in place of "long" for anything where the kernel uses "long". That means data from System.map and /proc at least. Stuff in /proc/*/stat becomes too big for sscanf() with %ld and a long. So I end up with a header file somewhat like this: #if defined(__sparc__) || defined(__mips__) || defined(__powerpc__) #define KLONG long long // not typedef; want "unsigned KLONG" to work #define KLF "L" #define STRTOUKL strtoull #else #define KLONG long #define KLF "l" #define STRTOUKL strtoul #endif There's a per-process struct full of /proc/*/stat data that grows a bit. So far, I've determined that these are affected: start_code, // address of beginning of code segment end_code, // address of end of code segment start_stack, // address of the bottom of stack for the process kstk_esp, // kernel stack pointer kstk_eip, // kernel instruction pointer wchan; // address of kernel wait channel proc is sleeping in There may be more fields affected. The data structures used to handle System.map grow quite a bit, with a KLONG for every line in the file. That looks to be about 80 kB for me. And so on... It adds up.