linux-kernel - Re: [2.6 patch] re-add -ffreestanding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Sep 2006 12:25:54 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Adrian Bunk <bunk@...sta.de>
cc:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6 patch] re-add -ffreestanding

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/