Re: [2.6 patch] re-add -ffreestanding

[Kyle Moffett]

On Aug 21, 2006, at 19:13:20, Andi Kleen wrote:
> > What's the problem with adding -ffreestanding and stating  
> > explicitely which functions we want to be handled be builtins, and  
> > which functions we don't want to be handled by builtins?
>
> Take a look at lib/string.c and think about it a bit.

So why can't lib/string.c explicitly say __builtin_foo() instead of  
foo() where we mean the former?  Here's a brief summary:

With -ffreestanding:
  __builtin_foo():  Use the GCC built-in if possible, otherwise out- 
of-line
  foo():            Always use the out-of-line function

Without -ffreestanding:
  __builtin_foo():  Use the GCC built-in if possible, otherwise out- 
of-line
  foo():            Use the GCC built-in if possible, otherwise out- 
of-line

What's wrong with always specifying -ffreestanding and using  
__builtin_foo() instead of foo() where applicable?  That's what it  
was designed for, according to the GCC manual:

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Options.html#C- 
Dialect-Options

If you want to unconditionally force a certain function to use the  
GCC built-in on a particular architecture, you could always just do  
this to get exactly the same result as without -ffreestanding:

#define memcpy(dest, src, len) __builtin_strcpy((dest), (src), (len))
#define memcmp(a, b, len) __builtin_strcmp((a), (b), (len))
[...]

Just stuff those types of defines in an x86-64 specific header  
somewhere and turn on -ffreestanding unconditionally; you'll fix all  
of the problems with MIPS, etc, without even changing the semantics  
on x86-64.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/