grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB2 Build on Mac OS X


From: Marco Gerards
Subject: Re: GRUB2 Build on Mac OS X
Date: Thu, 08 Dec 2005 19:45:29 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Peter Jones <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]