About x86-64 mcmodel=kernel and libgcc

[sham1]

So, in this wiki article, there is this part about how to get libgcc to compile and work with -mcmodel=kernel.

Compiling libgcc with -mcmodel=kernel
This may require a workaround. First compile binutils as usual, then add the binaries to the PATH, and start to compile gcc. When compiling libgcc with -mcmodel=kernel, it will fail. Then patch the Makefile to disable PIC, repeat and continue

Now the problem with this, of course, is the fact that one has to manually edit the Makefile during the build process. I've been trying to experiment with using GCC's target fragment files to try to make it so that for my cross-compiler, libgcc wouldn't be tried to be build with -fPIC enabled, because otherwise it will fail by saying that the kernel mcmodel does not support PIC. Various options including things like setting MULTILIB_OPTIONS into multiple orientations such as:

Code: Select all

MULTILIBS_OPTIONS = mcmodel=kernel/fpic mno-red-zone

and various other flags mentioned in the GCC documentation to try to make it so that the mcmodel=kernel-version of the libgcc would be build without -fPIC enabled. Even trying to set -fno-pic has thus far not been fruitful.
So I was wondering whether anyone else has had any better luck with this, or whether there really is no other way forwards other than to manually patch the Makefiles in the middle of the build.

Of course a possible solution would be to build libgcc with -mno-red-zone and -mcmodel=large, but that does seem rather inefficient.

[Octocontrabass]

Code: Select all

MULTILIBS_OPTIONS = mcmodel=kernel/fpic mno-red-zone

You mean MULTILIB_OPTIONS, right?

Could it be -fpie/-fPIE instead of or in addition to -fpic/-fPIC?

[kzinti]

I've just been through this. The problem is that the GCC source tree forces the use of -fpic for libgcc. To remove fpic from libgcc, you need to patch it.

Here is my patch to remove the default "-fpic" from libgcc (gcc 10.2.0): https://github.com/kiznit/build-gcc-and ... gure.patch

For multilib, I use a patch and a "target fragment file" as you suggested:
https://github.com/kiznit/build-gcc-and ... .gcc.patch
https://github.com/kiznit/build-gcc-and ... _64-kernel

So yes, I am afraid you do have to modify the distribution to be able to build libgcc with mcmodel=kernel.

You could of course just clone https://github.com/kiznit/build-gcc-and-binutils and write "make x86_64-elf", but where is the fun in that? (warning: this will use newlib instead of gnu's libc, but that's probably what you want anyways for kernel development).

[sham1]

I've just been through this. The problem is that the GCC source tree forces the use of -fpic for libgcc. To remove fpic from libgcc, you need to patch it.

Here is my patch to remove the default "-fpic" from libgcc (gcc 10.2.0): https://github.com/kiznit/build-gcc-and ... gure.patch

For multilib, I use a patch and a "target fragment file" as you suggested:
https://github.com/kiznit/build-gcc-and ... .gcc.patch
https://github.com/kiznit/build-gcc-and ... _64-kernel

So yes, I am afraid you do have to modify the distribution to be able to build libgcc with mcmodel=kernel.

You could of course just clone https://github.com/kiznit/build-gcc-and-binutils and write "make x86_64-elf", but where is the fun in that? (warning: this will use newlib instead of gnu's libc, but that's probably what you want anyways for kernel development).

Hmm, that's a shame. Although I feel that patching the sources themselves is less weird than having to patch the build system itself mid-build. After all, changing the sources is already required for disabling red zone, and for whenever one creates a more specific compiler for their system.

I'll try this approach. Maybe it should also be documented in the wiki.

[kzinti]

Maybe it should also be documented in the wiki.

I am working on getting libc and libc++ working in my bootloader and kernel. I've done libgcc and libc (newlib) so far, but am not done with libc++ because of reentrancy issues in interrupt and trap/fault handlers. Once I am, I intend to write a page with my findings.

I'll try this approach.

One thing to keep it mind is that on x86_64, GCC will use XMM registers when compiling libgcc. This isn't true for most functions, but it is for some of them (for example, the stack unwinding code used for exception handling). It is of course possible to compile libgcc with "-mgeneral-regs-only", but if you try that, you need to remove some functions from libgcc that use floats/doubles. I first went that route but gave up when I got the libstdc++-v3 after painfully patching newlib itself.