Re: [m68k] in modpost: "strlen" [iscsi_target_mod.ko] undefined! (and others)

[Jonathan Nieder <jrnieder@gmail.com>]

Thorsten Glaser wrote:

> I’d rather know why upstream doesn’t use -ffreestanding on
> _all_ architectures. A kernel is _not_ a hosted environment,
> and GCC is right to bring in problems like this.

It's to make optimizations that use the builtin functions (e.g.,
memcpy) work with less fuss.  If the kernel implements all the
relevant library functions, then it can be considered hosted as far as
GCC cares.

[...]
>                                (Nobody prevents GCC from using
> a memcpy builtin that uses, say, SSE instructions

Doesn't -mno-sse take care of that?

However, if you (this is the general "you", not just Thorsten) find
the following reasoning[1] compelling, feel free to propose a patch to
Makefile instead of arch/m68k/Makefile.  If others agree, some patches
for the x86 string functions to get the optimizations back could
follow, leaving everyone happy.

Ciao,
Jonathan

[1]
commit d6326c18
Author: Adrian Bunk <bunk@stusta.de>
Date:   Tue Jan 4 05:29:33 2005 -0800

    [PATCH] compile with -ffreestanding

    For the kernel, it would be logical to use -ffreestanding.  The kernel is
    not a hosted environment with a standard C library.

    The gcc option -ffreestanding is supported by both gcc 2.95 and 3.4, which
    covers the whole range of currently supported compilers.

    Regarding changes caused by this patch:

    Andi Kleen reported:
      Newer gcc rewrites sprintf(buf,"%s",str) to strcpy(buf,str) transparently.

    This is only true with unit-at-a-time (disabled on i386 but enabled on
    x86_64).  The Linux kernel doesn't offer a standard C library, and such
    transparent replacements of kernel functions with builtins are quite
    fragile.

    Even with -ffreestanding, it's still possilble to explicitely use a gcc
    builtin if desired.