Re: [PATCH 0/6] m68k: merge and clean up files in m68k/lib

[Greg Ungerer <gerg@snapgear.com>]

Hi Andreas,

On 07/04/11 18:22, Andreas Schwab wrote:
> Greg Ungerer<gerg@snapgear.com>  writes:
>
>> That does seem odd. One way or another strcpy is defined in
>> arch/m68k/include/asm/string.h. I would expect no real calls to
>> strcpy() after that. (And for me on my hand built gcc-4.5.1 I
>> don't end up with any).
>
> Did you compile with -Os?

No, -O2. Here is a typical gcc line:

m68k-linux-gcc -Wp,-MD,kernel/.printk.o.d  -nostdinc -isystem 
/usr/local/lib/gcc/m68k-linux/4.5.1/include 
-I/home/gerg/new-wave.merge/linux-2.6.x/arch/m68k/include -Iinclude 
-include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security 
-fno-delete-null-pointer-checks -O2 -pipe -fno-strength-reduce 
-ffixed-a2 -Wframe-larger-than=1024 -fno-stack-protector 
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO 
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(printk)" 
-D"KBUILD_MODNAME=KBUILD_STR(printk)" -c -o kernel/printk.o kernel/printk.c

This is vanilla 2.6.39-rc2...


>> At a guess the section for __GNUC__>  4 must end up still trying
>> to use a real strcpy (presumably the __builtom_strcpy call) on
>> some versions of gcc.
>>
>> #if __GNUC__>= 4
>> #define strcpy(d, s)    (__builtin_constant_p(s)&&      \
>>                           __builtin_strlen(s)<= 32 ?    \
>>                           __builtin_strcpy(d, s) :       \
>>                           __kernel_strcpy(d, s))
>> #else
>> #define strcpy(d, s)    __kernel_strcpy(d, s)
>> #endif
>>
>> Is there any reason we don't just drop the __GNUC__>= 4 bit
>> and always just use __kernel_strcpy()?  After all kernel_strcpy
>> is a pretty tight optimized loop for m68k anyway.
>
> The compiler can generate libcalls to strcpy any time while optimizing
> any other standard C function, and those libcalls won't see the macros,
> of course.  The only way to stop the compiler from doing that is to
> disable all builtin functions (just -fno-builtin-strcpy is not enough),
> but that would disable a lot of useful opimisations.

Yes, ok. It is just that I hadn't seen gcc emit calls to strcpy
on my m68knommu builds (at least not in recent years since we
removed the local strcpy).

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com