Re: Bug#648996: linux-2.6: FTBFS [m68k] in modpost: "strlen" [iscsi_target_mod.ko] undefined! (and others)

Re: Bug#648996: linux-2.6: FTBFS [m68k] in modpost: "strlen" [iscsi_target_mod.ko] undefined! (and others)

[Thorsten Glaser]

Dixi quod…

>I suspect gcc emitting a call to strFOO for __builtin_strFOO.

And indeed, it does; waldi just pointed me to the fact that the
Linux kernel, despite being a kernel and not a hosted environment,
does not use -ffreestanding in its CFLAGS. No surprise it does
that, then.

When I first upgraded from gcc 2.x to gcc 3.x in MirBSD, the kernel
inherited from OpenBSD had similar issues, and adding -ffreestanding
as should be fixed that.

So, please, compile the Linux kernel with -ffreestanding, too.

bye,
//mirabilos
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.	-- Ragge
No faith left in ISO C99, undefined behaviour, etc.

Re: Bug#648996: linux-2.6: FTBFS [m68k] in modpost: "strlen" [iscsi_target_mod.ko] undefined! (and others)

[Thorsten Glaser]

Dixi quod…

>So, please, compile the Linux kernel with -ffreestanding, too.

Just to keep this bugreport in the loop: that fixes the FTBFS error.
http://lists.debian.org/debian-68k/2012/01/msg00000.html

bye,
//mirabilos
-- 
<dileks> ch: good, you corrected yourself. ppl tend to tweet such news
immediately, sth. like "grml devs seem to be buyable"    <ch> dileks: we
_are_. if you throw enough money in our direction, things will happen
<mika> everyone is buyable, it's just a matter of price   <mrud> and now
comes [mira] and uses this as a signature ;0	   -- they asked for it…

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

[Jonathan Nieder]

Thorsten Glaser wrote[1]:
> Dixi quod…

>> So, please, compile the Linux kernel with -ffreestanding, too.
>
> Just to keep this bugreport in the loop: that fixes the FTBFS error.

Yep, sounds like a reasonable idea, though these calls to
"strncat(buf, str, strlen(str))" in the iscsi driver are still a
little insane.  Could you suggest a patch to arch/m68k/Makefile to do
that?

Thanks,
Jonathan

[1] http://bugs.debian.org/648996

Background:

commit 6edfba1b33c7
Author: Andi Kleen <ak@suse.de>
Date:   Sat Mar 25 16:29:49 2006 +0100

    [PATCH] x86_64: Don't define string functions to builtin

    gcc should handle this anyways, and it causes problems when
    sprintf is turned into strcpy by gcc behind our backs and
    the C fallback version of strcpy is actually defining __builtin_strcpy

    Then drop -ffreestanding from the main Makefile because it isn't
    needed anymore and implies -fno-builtin, which is wrong now.
    (it was only added for x86-64, so dropping it should be safe)

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

[Thorsten Glaser]

Jonathan Nieder dixit:

>Could you suggest a patch to arch/m68k/Makefile to do that?

No, I patched it in debian/config/m68k/defines instead.

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.

>    Then drop -ffreestanding from the main Makefile because it isn't
>    needed anymore and implies -fno-builtin, which is wrong now.

This is wrong, GCC builtins are only valid on hosted platforms,
not on freestanding platforms. (Nobody prevents GCC from using
a memcpy builtin that uses, say, SSE instructions, which must
not be used inside kernel code, for an example on a better-known
architecture.) A kernel must always be compiled freestanding,
as do bootloaders. At least since the advent of gcc 3.[34].

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

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

[Jonathan Nieder]

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.

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

[Thorsten Glaser]

Jonathan Nieder dixit:

>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.
[…]
>    Even with -ffreestanding, it's still possilble to explicitely use a gcc
>    builtin if desired.

Just call them, like this:

tg@zigo:~/Xl/linux-2.6-3.2~rc7 $ fgrep -A 3 "define strcpy" arch/m68k/include/asm/string.h
#define strcpy(d, s)    (__builtin_constant_p(s) &&     \
                         __builtin_strlen(s) <= 32 ?    \
                         __builtin_strcpy(d, s) :       \
                         __kernel_strcpy(d, s))

Of course, the parameters when to call which may differ.
(The choice about being a hosted environment is not just
about having libc-like functions available.)

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.		-- Andreas Bogk über boehm-gc in d.a.s.r