[PATCH] arm64: kill off the libgcc dependency

[Will Deacon]

On Wed, Jan 14, 2015 at 12:52:49PM +0000, Ard Biesheuvel wrote:
> On 14 January 2015 at 12:38, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Wednesday 14 January 2015 11:48:27 Will Deacon wrote:
> >> On Wed, Jan 14, 2015 at 11:35:22AM +0000, Arnd Bergmann wrote:
> >> > On Wednesday 14 January 2015 10:48:26 Will Deacon wrote:
> >> > > On Wed, Jan 14, 2015 at 10:38:54AM +0000, Kevin Hao wrote:
> >> > > > 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?
> >>
> >> 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.
> >
> >> > 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.
> >
> 
> 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.

Will