From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EkQm8-0007aV-Tj for mharc-grub-devel@gnu.org; Thu, 08 Dec 2005 13:45:52 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EkQm6-0007ZR-In for grub-devel@gnu.org; Thu, 08 Dec 2005 13:45:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EkQm4-0007Ye-Ot for grub-devel@gnu.org; Thu, 08 Dec 2005 13:45:49 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkQm4-0007YZ-FQ for grub-devel@gnu.org; Thu, 08 Dec 2005 13:45:48 -0500 Received: from [194.109.24.24] (helo=smtp-vbr4.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EkQn8-0002O0-Ak for grub-devel@gnu.org; Thu, 08 Dec 2005 13:46:54 -0500 Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by smtp-vbr4.xs4all.nl (8.13.3/8.13.3) with ESMTP id jB8IjRWK071452 for ; Thu, 8 Dec 2005 19:45:28 +0100 (CET) (envelope-from mgerards@xs4all.nl) Mail-Copies-To: mgerards@xs4all.nl To: The development of GRUB 2 References: <878xuvsrl1.fsf@xs4all.nl> <1134059234.15370.23.camel@localhost.localdomain> From: Marco Gerards Date: Thu, 08 Dec 2005 19:45:29 +0100 In-Reply-To: <1134059234.15370.23.camel@localhost.localdomain> (Peter Jones's message of "Thu, 08 Dec 2005 11:27:13 -0500") Message-ID: <87u0djmnqu.fsf@xs4all.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: GRUB2 Build on Mac OS X X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2005 18:45:51 -0000 Peter Jones writes: > On Thu, 2005-12-08 at 13:26 +0100, Marco Gerards wrote: > >> It's not acceptable to me to just remove the nested functions because >> someone broke some unofficial build of gcc. When an executable stack >> is not available, there are the following options (as I see them): > > I could be wrong, but GCC appears not to have official builds. For any > platform. Right, what I meant to say is an official release. A documented feature from gcc was simply discarded. > That being said, what's the reasoning for using this uncommon and > lossely defined extension in the first place? The way GRUB (both 2 and > Legacy) uses nested functions, it's no better than just having a method > vector, and certainly not easier to read. Not only that, but the trend > going forward is towards *less* support of executable stacks, not more. > I wouldn't expect that to stop with us and for Apple, especially now > that there's widespread support for non-executable pages on Intel > hardware. > > For that matter, is there a specific intent to use GNU C rather than > ANSI/ISO C? I haven't extensively read the list archives, so feel free > to point me at them if this has been widely discussed. It's a GNU feature, GRUB is a GNU project. And it is widely used in GRUB 2, we like GNU99 (or at least I do). So if you are looking at this from that perspective, it is not that uncommon or weird at all. > Are you saying you don't want Would you be amicable to patches which > change code from using nested functions to a more C-like implementation? > (I don't mean like the patch in my current GRUB Legacy package; > something cleaner than that hacky approach.) Right. If there is no good reason for such thing (some random gcc hack isn't a good reason for me), I see no reason to change it. >> Enable the executable stack using: >> 1) Set some bit in the ELF file so the OS knows we want this >> (that's what linux does). >> 2) Enable it using some function. >> 3) Creating our own stack. > > There's a major point of contention being ignored here. OS vendors > don't want to ship executables which require an executable stack. Full > stop. Please give me one good reason why GRUB shouldn't use an executable stack. I don't see a good reason besides the more general "We don't want to have executable stacks at all". >> So on the apple the right thing to do would be: >> >> 1) Fix gcc so nested functions are not fatal. > >>>From many points of view, this would not be "fixing" GCC. > >> 2) fix GRUB using the methods I described above. > > Likewise. Why wouldn't it be? Anyways, it would be nice if gcc could support nested functions by using something else than an executable stack. Thanks, Marco