replacing kernel for 32-bit system
 

I'm sorry for asking an old question.

In my understanding, it seems possible to replace the kernel of a purely 32-bit system with a 64-bit kernel.
It sounds natural that the 32-bit executables will run on such a "hybrid" system, but I concern about the effect on the development environment.
As the original tools (binutils, gcc, glibc, etc) are all 32-bit, will they take care of the inconsistency with the kernel and run correctly under the hybrid system ?

Sorry guy, but I think I do not understand: What do you mean by that?
It is impossible (to replace only the kernel), but you need to replace all the drivers, and a lot of other things too. That means you need to install a 64bit OS. And a 64bit os is capable to run 32bit programs, and the development environment is not an exception.
Probably you mean multiarch os, but I do not really understand you.

Exactly so: the 64-bit capable hardware now runs in its native, 64-bit mode. The kernel is compiled to run 64-bit instructions and to build the virtual-memory (et al) data structures needed by the CPU in that mode. And-d-d-d... this change necessarily bubbles all the way to the top of the entire software stack. A 64-bit version of "glibc" must be available. 64-bit executables must be used as often as possible (although 64-bit Linux can deploy a process in 32-bit compatibility mode).

Situations that involve the running of 64- and 32-bit software "at the same time" (a) can only be done at the application level, and (b) are very inefficient and awkward. The term, "thunking," is very apropos. :D ("Clunking, Wheezing, and Spewing Smoke" would also be appropriate. Yes, it can be done. No, you'd prefer not to be doing it. You have a racehorse: don't put hobbles and blinkers on it.)

Thank you for your explanations.

It is of course an intuitive assumption that system executables should match the kernel, but it is not groundless as I wrote
I've conducted an experiment using a pre-compiled kernel and an initrd image from an earlier Slackware distribution :

• Firstly I retrieved a 64-bit kernel from "slackware64-x.x/kernels/huge.s/bzImage" and a 32-bit initrd image from "slackware-x.x/isolinux/initrd.img"
• All the downloaded files were then copied to a bootable FAT partition with SYSLINUX installed.
• At the "boot:" prompt I entered the parameters :
  
  Code:

  ---

  bzImage root=/dev/ram initrd=initrd.img rw

  ---

• The booting process was completed successfully. Commands from coreutils, util-linux, etc seemed to work as usual, and "uname -m" returns "x86_64".

The experiment was repeated using the combination of 32-bit kernel and 64-bit initrd, but it failed to boot then.

The result of the experiments, I think, indicates the possibility of constructing a hybrid system with 32-bit executables and a 64-bit kernel, and this is the reason for my asking the question about the behaviour of development tools.

please read this: https://en.wikipedia.org/wiki/Initrd (and the link to the linux startup process)

It is totally possible to use a 32 bit userland on top of a 64 bit kernel, this configuration just works, no 64 bit glibc and no other 64 bit parts in the software stack are needed (for anyone not believing that: go ahead and try it, you will see). You will only need a 64 bit software stack if you actually plan to use 64 bit software, or if you need proprietary drivers for your AMD videocard, these drivers don't support this configuration (don't know for Nvidia, never tried that).

Tobi, of course you are technically correct: the 64-bit kernel can run a 32-bit userland stack. The x86 microprocessor (for instance) has well-defined architectural support for that. But this is not what is typically done, nor if at all possible should (IMHO) be done, because ... even though the kernel can use "all that 64-bit goodness" to make full use of what this CPU can do, the individual userland processes are firmly stuck in the past. The kernel can exploit 64-bit mode to run a whole bunch of "2/4 gigs max" virtual address spaces in a machine with capacious RAM capacity, but those processes, as individuals, are still stuck with that individual limitation.

Most systems that I see will have two sets of libraries ... 64 bit and 32 bit ... side-by-side in userland.

Of course, a 32 bit program will still be limited to 32 bit. If it should be done, well, some kernel developers think different about that topic than you and I personally see nothing wrong with it.

TobiSGD, thank you for your justification.

I fully understand that such a hybrid system is meant to be experimental, but I'm interested in program compilation therein, e.g. when building software packages from sources.
It is expected that 32-bit development tools and library can only produce 32-bit executables. But if architecture detection is involved (e.g. in most "configure" scripts), will the inconsistency with the kernel break the compilation ?

the compilation itself is not related to the kernel. The kernel is only used to run the tools you use and the result will only depend on the tools you have. You can use the -march=<something> to specify the target architecture

Thanks for the answers.