clang libgcc red zone

[EatMoreCookies3]

After reading through most of the wiki I want to confirm a couple of things. Currently I've built a gcc x86_64-elf cross compiler, for the kernel, and an x86_64-w64-mingw32 compiler for the UEFI bits. I also built libgcc without the red zone. I'd like to get down to a single compiler so am looking at the LLVM tools.

As it pertains to clang I've read several tutorials on the internet which don't mention using a libgcc compiled without red zone support. Adding "-mno-red-zone" to the clang command line is as far as it goes. But it seems to me I would still want to link against the libgcc made without red zone. So question #1: Is that an accurate understanding?

I also see that LLVM now has a not-fully-complete implementation of libc. If I were to use their libc I assume I would want to compile it without red zone support. I recognize this group is primarily geared toward the gnu toolset but it "should be as simple" as adding the -mno-red-zone to the build command when compiling the LLVM libc. So question #2: Does that seem reasonable or am I missing something obvious?

See https://libc.llvm.org/full_host_build.html for the LLVM libc build instructions

Thanks in advance!

[EatMoreCookies3]

After thinking on this more, and re-reading some of Libgcc page on the wiki (https://wiki.osdev.org/Libgcc) states that "all code compiled by GCC must be linked with libgcc" For some reason I assumed that also meant that clang would have the same requirement. Towards the bottom of the same document it says "I'm using clang: This article is about GCC, you need to do different things if you are using another compiler". Touche!

But, continuing to search the forums brought this post from 2019 to my attention (viewtopic.php?t=36341) and the poster is clearly linking to libgcc using the clang compiler:

clang -T linker.ld -o myos.bin -ffreestanding -O2 -nostdlib boot.o kernel.o -lgcc

Is this an erroneous step?

Thanks again!

[EatMoreCookies3]

I think I found an answer to whether I should include -lgcc as a linker option.

Per https://clang.llvm.org/docs/Toolchain.h ... er-runtime:

A number of different runtime libraries are required to provide different layers of support for C family programs. Clang will implicitly link an appropriate implementation of each runtime library, selected based on target defaults or explicitly selected by the --rtlib= and --stdlib= flags.

LLVM’s compiler runtime library provides a complete set of runtime library functions containing all functions that Clang will implicitly call, in libclang_rt.builtins.<arch>.a.

GCC’s runtime library can be used in place of compiler-rt. However, it lacks several functions that LLVM may emit references to, particularly when using Clang’s __builtin_*_overflow family of intrinsics.

So it would seem that clang auto-magically handles this on its own...

[nullplan]

After thinking on this more, and re-reading some of Libgcc page on the wiki (https://wiki.osdev.org/Libgcc) states that "all code compiled by GCC must be linked with libgcc"

Wow, that statement is just flat-out false.

Libgcc contains support routines that gcc may insert calls to when compiling C code. If that happens, you must provide an implementation of the routine somehow, and linking in libgcc is one way to do it. Another way is to just implement the functions yourself in assembler. However, I struggle to think of anything in a C kernel on x86_64 that may cause gcc to emit such calls. My policy has therefore always been to just not link it in and fix linker errors as they appear.

Clang has the same thing, except it calls the library libcompiler-rt. I would simply do the same thing there.

In C++, these libraries also provide the personality routine for the exception handler. And I think the basic RTTI. But anyway, if you avoid those features, you should be fine.

[Octocontrabass]

But it seems to me I would still want to link against the libgcc made without red zone. So question #1: Is that an accurate understanding?

Yes. (If you write your own libgcc/compiler-rt replacement, you'd want that code to be compiled without the red zone too.)

So question #2: Does that seem reasonable or am I missing something obvious?

If you're planning on using LLVM-libc in your kernel, yes, you'd need to disable the red zone there too. But I'm not sure if LLVM-libc will work in a kernel; it's designed for hosted environments (userspace) and might have dependencies that are hard to satisfy elsewhere.