Re: bloat tolerance?
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.
Reply to: