Re: [2.6 patch] re-add -ffreestanding

From: Roman Zippel
Date: Thu Sep 07 2006 - 06:26:23 EST


Hi,

On Thu, 7 Sep 2006, Adrian Bunk wrote:

> > > > Define "full libc".
> > >
> > > Everything described in clause 7 of ISO/IEC 9899:1999.
> >
> > Its behaviour is also defined by the environment, so what gcc can assume
> > is rather limited and you have not shown a single example, that any such
> > assumption would be invalid for the kernel.
>
> ISO/IEC 9899:1999 clause 7 defines the libc part of a hosted environment.

Which is a problem for the kernel exactly how?
BTW the standard specifies the minimum requirements for a libc, so talking
about "full libc" is ambiguous at best.

> > The kernel uses standard C, so your point is?
>
> A standard C freestanding environment or a standard C hosted environment?

As far as gcc is concerned it's a hosted environment, where we provide
only what we actually use, but anything we do provide is compliant.

> > You already got two NACKs from arch maintainers, why the hell are you
> > still pushing this patch? The builtin functions are useful and you want to
>
> The same people who justified removing -ffreestanding with the "it was
> only added for x86-64, so dropping it should be safe" that has proven
> wrong now put their arch maintainers hats on for NACKing reverting this
> patch...

And you keep ignoring there might be better solutions...

> > force arch maintainers to have to enable every single one manually and
> > to maintain a list of these functions over multiple versions of gcc?
>
> It could be done per architecture or globally for some functions.
>
> And it doesn't sound like a bad idea to check the current code and think
> of what it does and what it should do - many architecture specific
> things (like much of include/asm-i386/string.h) seem to be more
> historically than architecture specific.

We're happy to hear about it, once you've done this.

bye, Roman
-
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/