audit compiler-rt

[andrewrk]

Zig's compiler-rt is a maintained port of LLVM's compiler-rt. This means we need to track upstream.

From now on, the policy is to document each compiler-rt function with the svn revision id of compiler-rt that the function was ported from. For existing functions, add this documentation comment once auditing the code with the latest code.

Then, when upgrading to new LLVM versions, we will do a svn diff on compiler-rt to find out what has changed upstream, make any necessary changes in zig, and update the comment to the new svn revision.

Added to LLVM Upgrade Process

[justinbalexander]

I'm confused about how to port some of this for ARM.

https://github.com/llvm/llvm-project/blob/3b0a6c69ee54fbe3a873adca35fa9b282121fb3d/compiler-rt/lib/builtins/arm/aeabi_memcpy.S#L11

It defines the arm builtin __aeabi_memcpy to be a wrapped call to memcpy itself.

How can I do that in just Zig? A call to std.mem.copy turns into another call to __aeabi_memcpy.

I could write my own assembly memcpy, but then I'm not really porting the compiler-rt.

Since Zig will soon include libc for cross-compilation, would it be easier to also include llvm's compiler-rt instead of maintaining a separate one?

[andrewrk]

How can I do that in just Zig? A call to std.mem.copy turns into another call to __aeabi_memcpy.

The llvm compiler_rt code is in arm assembly, so you can just put that into zig's compiler rt. Maybe that doesn't feel like porting it, but the end result is that now we have the function available from zig whereas before we didn't.

zig/std/special/compiler_rt.zig

Lines 186 to 200 in 6acabd6

	nakedcc fn __aeabi_uidivmod() void {
	@setRuntimeSafety(false);
	asm volatile (
	\\ push { lr }
	\\ sub sp, sp, #4
	\\ mov r2, sp
	\\ bl __udivmodsi4
	\\ ldr r1, [sp]
	\\ add sp, sp, #4
	\\ pop { pc }
	:
	:
	: "r2", "r1"
	);
	}

Since Zig will soon include libc for cross-compilation, would it be easier to also include llvm's compiler-rt instead of maintaining a separate one?

Libc is not relevant here - compiler-rt does not depend on libc. It is possible for zig to build c files from source, and build compiler-rt from source in this way rather than maintaining a port. That is worth considering. However we've already done a lot of progress without depending on a C compiler. Even the .c code that zig builds from source such as glibc startup files, we want to transition to being in .zig source form eventually. Zig code does build faster, we have a little bit more control over symbol visibility, and it brings us closer to a possible future where there is another Zig compiler which does not have any translate-c/clang functionality (or depend on LLVM) and it is still viable. In general we want to move toward that being possible, not away.

[justinbalexander]

I had thought libc was relevant because the call to memcpy has to go somewhere. Where does memcpy come from in this case? Also, how can I switch on builtin.Arch.Arm32? The assembly is different for armv6 vs armv7. I need to differentiate those but can't figure out how.

…

On Sun, Mar 17, 2019, 1:51 PM Andrew Kelley ***@***.***> wrote: How can I do that in just Zig? A call to std.mem.copy turns into another call to __aeabi_memcpy. The llvm compiler_rt code is in arm assembly, so you can just put that into zig's compiler rt. Maybe that doesn't feel like porting it, but the end result is that now we have the function available from zig whereas before we didn't. https://github.com/ziglang/zig/blob/6acabd6b577ac63274b31bd1b2ae22cc75ab2c7a/std/special/compiler_rt.zig#L186-L200 Since Zig will soon include libc for cross-compilation, would it be easier to also include llvm's compiler-rt instead of maintaining a separate one? Libc is not relevant here - compiler-rt does not depend on libc. It is possible for zig to build c files from source, and build compiler-rt from source in this way rather than maintaining a port. That is worth considering. However we've already done a lot of progress without depending on a C compiler. Even the .c code that zig builds from source such as glibc startup files, we want to transition to being in .zig source form eventually. Zig code does build faster, we have a little bit more control over symbol visibility, and it brings us closer to a possible future where there is another Zig compiler which does not have any translate-c/clang functionality (or depend on LLVM) and it is still viable. In general we want to move toward that being possible, not away. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1504 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Alxei_IibSmcLpQnlwRfOjZI1mL_FBHZks5vXo7AgaJpZM4WkFBr> .

[andrewrk]

You can use zig builtin to see the relevant types. The output is also available here: https://ziglang.org/documentation/master/#Compile-Variables

So it's the same thing as switching on a union(enum): https://ziglang.org/documentation/master/#switch

[daurnimator]

Is zig meant to be compatible with LLVM's compiler-rt?

At least on x86 and i386, zig code looks for the __zig_probe_stack symbol, which when linking against llvm-libs compiler_rt, is missing.

[andrewrk]

That's sort of an open design question right now. The feature that __zig_probe_stack provides is optional. We would like it to be enabled by default (in safe build modes) if we know that there will be a zig-generated compiler-rt, but we could just as easily omit a dependency on that symbol if that was not guaranteed. For now you can pass -fno-stack-check to avoid a dependency on __zig_probe_stack.