arm64: kill off the libgcc dependency

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Quoted 1 line · Kevin Hao

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Yes it does; we make use of __builtin_* for our bitops, for example. The compiler guys don't guarantee that these will be inlined.

Quoted 5 lines · On Wednesday 14 January 2015 10:48:26 Will Deacon wrote:

Quoted 1 line · Kevin Hao

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Yes it does; we make use of __builtin_* for our bitops, for example. The compiler guys don't guarantee that these will be inlined.

Is that an architecture-specific statement?

The debate has been going on for ages in Linux, most architecture maintainers however decided against using libgcc and copy the functions that are actually needed into the kernel sources.

Quoted 4 lines · Arnd Bergmann

Quoted 3 lines · On Wednesday 14 January 2015 10:48:26 Will Deacon wrote:

Quoted 1 line · Kevin Hao

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Quoted 4 lines

Quoted 2 lines

Yes it does; we make use of __builtin_* for our bitops, for example. The compiler guys don't guarantee that these will be inlined.

Is that an architecture-specific statement?

I think the inlining guarantees apply to all architectures, but it affects the arm64 kernel because we include <asm-generic/bitops/builtin-*>.

Quoted 3 lines

The debate has been going on for ages in Linux, most architecture maintainers however decided against using libgcc and copy the functions that are actually needed into the kernel sources.

What's the benefit of copying them?

Quoted 5 lines · On Wednesday 14 January 2015 11:48:27 Will Deacon wrote:

Quoted 4 lines · Arnd Bergmann

Quoted 3 lines · On Wednesday 14 January 2015 10:48:26 Will Deacon wrote:

Quoted 1 line · Kevin Hao

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Yes it does; we make use of __builtin_* for our bitops, for example. The compiler guys don't guarantee that these will be inlined.

Is that an architecture-specific statement?

I think the inlining guarantees apply to all architectures, but it affects the arm64 kernel because we include <asm-generic/bitops/builtin-*>.

Is it realistic to expect those to ever be implemented out of line? I would expect them to behave like assembler intrinsics, at least with the normal optimization level.

Quoted 5 lines

Quoted 3 lines

The debate has been going on for ages in Linux, most architecture maintainers however decided against using libgcc and copy the functions that are actually needed into the kernel sources.

What's the benefit of copying them?

You have a better control over what is included. On 32-bit architectures, the 64-bit division is notorious here, we really don't want to accidentally call the libgcc implementation but instead have our own do_div() helper.

Similarly I'd think that if we get a compiler that uses an external __ffs implementation, we should implement an inline assembly instead of taking the libgcc version.

Another problem that has happened in the past is libgcc functions that in turn call glibc functions. To avoid that, you'd really want to build the kernel with -ffreestanding, but that opens another can of worms.

Quoted 32 lines · Arnd Bergmann

Quoted 5 lines · On Wednesday 14 January 2015 11:48:27 Will Deacon wrote:

Quoted 4 lines · Arnd Bergmann

Quoted 3 lines · On Wednesday 14 January 2015 10:48:26 Will Deacon wrote:

Quoted 1 line · Kevin Hao

The arm64 doesn't depend on the libgcc to build the vmlinux image.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Yes it does; we make use of __builtin_* for our bitops, for example. The compiler guys don't guarantee that these will be inlined.

Is that an architecture-specific statement?

I think the inlining guarantees apply to all architectures, but it affects the arm64 kernel because we include <asm-generic/bitops/builtin-*>.

Is it realistic to expect those to ever be implemented out of line? I would expect them to behave like assembler intrinsics, at least with the normal optimization level.

Quoted 5 lines

Quoted 3 lines

The debate has been going on for ages in Linux, most architecture maintainers however decided against using libgcc and copy the functions that are actually needed into the kernel sources.

What's the benefit of copying them?

You have a better control over what is included. On 32-bit architectures, the 64-bit division is notorious here, we really don't want to accidentally call the libgcc implementation but instead have our own do_div() helper.

Similarly I'd think that if we get a compiler that uses an external __ffs implementation, we should implement an inline assembly instead of taking the libgcc version.

Quoted 4 lines

Another problem that has happened in the past is libgcc functions that in turn call glibc functions. To avoid that, you'd really want to build the kernel with -ffreestanding, but that opens another can of worms.

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

Quoted 3 lines · Ard Biesheuvel

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

That's a very good point. In which case, we'd need to extend this patch to implement the bitops that we currently rely on the __builtins for.

Quoted 5 lines · Will Deacon

Quoted 3 lines · Ard Biesheuvel

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

Quoted 2 lines

That's a very good point. In which case, we'd need to extend this patch to implement the bitops that we currently rely on the __builtins for.

Sorry, I am not sure I get what you mean. These builtin functions for bitops are not implemented in the libgcc, they are inlined in compiler. So why do we need to reimplement these bitops when removing the link with libgcc?

Quoted 9 lines · Kevin Hao

Quoted 7 lines · Will Deacon

Quoted 3 lines · Ard Biesheuvel

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

That's a very good point. In which case, we'd need to extend this patch to implement the bitops that we currently rely on the __builtins for.

Quoted 3 lines

Sorry, I am not sure I get what you mean. These builtin functions for bitops are not implemented in the libgcc, they are inlined in compiler. So why do we need to reimplement these bitops when removing the link with libgcc?

I'm just relaying what the tools guys told us. Namely, that they don't guarantee that they are inlined and could generate a branch to a libgcc function. As Ard says, they could also use fpsimd registers, so whether or not they are inlined is moot anyway.

Quoted 14 lines · Will Deacon

Quoted 12 lines · Kevin Hao

Quoted 7 lines · Will Deacon

Quoted 3 lines · Ard Biesheuvel

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

That's a very good point. In which case, we'd need to extend this patch to implement the bitops that we currently rely on the __builtins for.

Sorry, I am not sure I get what you mean. These builtin functions for bitops are not implemented in the libgcc, they are inlined in compiler. So why do we need to reimplement these bitops when removing the link with libgcc?

Quoted 5 lines

I'm just relaying what the tools guys told us. Namely, that they don't guarantee that they are inlined and could generate a branch to a libgcc function. As Ard says, they could also use fpsimd registers, so whether or not they are inlined is moot anyway.

Which builtins are you referring to, exactly?

~/linux-2.6$ git grep __builtin arch/arm64
arch/arm64/kernel/module.c:
__builtin_return_address(0));
arch/arm64/kernel/return_address.c: frame.fp = (unsigned
long)__builtin_frame_address(0);
arch/arm64/kernel/stacktrace.c: frame.fp = (unsigned
long)__builtin_frame_address(0);
arch/arm64/kernel/traps.c: frame.fp = (unsigned
long)__builtin_frame_address(0);
arch/arm64/mm/ioremap.c:
__builtin_return_address(0));
arch/arm64/mm/ioremap.c:
__builtin_return_address(0));

none of which would ever require library support, as far as I can judge, and the arm64 kernel builds fine with -fno-builtin added (i.e., builtins can only be invoked explicitly using their __builtin- alias) and libgcc.a removed.

Quoted 8 lines · Arnd Bergmann

You have a better control over what is included. On 32-bit architectures, the 64-bit division is notorious here, we really don't want to accidentally call the libgcc implementation but instead have our own do_div() helper.

Similarly I'd think that if we get a compiler that uses an external __ffs implementation, we should implement an inline assembly instead of taking the libgcc version.

Quoted 4 lines

Another problem that has happened in the past is libgcc functions that in turn call glibc functions. To avoid that, you'd really want to build the kernel with -ffreestanding, but that opens another can of worms.

IMO libgcc.a cannot be used at all in the kernel, as it is not built with -mgeneral-regs-only so we have no guarantee that it will leave the NEON registers alone.

It's actually exactly issues like this which have prompted the kernel to use its own libgcc on many architectures.

Not only is it what Arnd says above, but it's also to do with making sure that we know what goes into the kernel is sane.

Although libgcc is part of the compiler, libgcc is built with the expectation that it will be running in userland - it expects to link to a libc. That's why you can't build libgcc without having the glibc headers around.

For example, on ARM, libgcc.a may contain calls to __div0, and it may provide its own __div0 implementation, which invokes various Linux system calls.

Various functions reference _GLOBAL_OFFSET_TABLE_ which we don't want to have in the kernel.

Depending on how the compiler was built, libgcc.a may be built for ARMv4, ARMv5, ARMv6 or ARMv7, and may not be appropriate for linking with the kernel. (Eg, you wouldn't want to try to link an ARMv7 libgcc.a in an ARMv5 kernel - and we /really/ don't want the mess of having different toolchains for different ARM arch versions.)

It may also drag in the userspace exception unwind support.

Meanwhile, having the kernel build the compiler support functions that it needs ensures that (a) we know what compiler support functions are being used, (b) we know the implementation of those support functions are sane for use in the kernel, (c) we can build them with appropriate compiler flags for best performance, and (d) we remove an unnecessary dependency on the build toolchain.