2012/4/28 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
> On 27.04.2012 20:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 27.04.2012 16:05, Albert Zeyer wrote:
>>> * Write a simplified compile.py script.
>> We don't have any compile.py.
>>> * Remove nested functions. They don't work on Mac because of stack
>>> execution protection.
>> It can be disabled. It's Apple fault for not allowing to disable it
>> selectively. Replacing nested functions is possible if done properly but
>> the "let's make it all static" is wrong and will create problems with
>> recursion, i.a. with nested partitions.
> And actually nested functions don't matter. What does are trampolines
> and they are only emitted it nested functions access local variables of
> parent and not inlined.
Hi,
I think mac is not alone, netbsd uses non-executable stack and heap as
well. Anyway, lower system security just to run an application does
seem a little undesirable.
I once wrote a small framework to get rid of the nasty trampolines, for example:
#define DEFINE_CLOSURE struct __closure_struct {
#define DEFINE_CLOSURE_END } __closure_data;
#define CLOSURE_TYPE void *__closure
#define CLOSURE __closure
#define CLOSURE_DATA &__closure_data
#define USE_CLOSURE struct __closure_struct *__closure_p = __closure;
#define UNUSED_CLOSURE (void) __closure;
#define _C(a) __closure_p-> a
#define _D(a) __closure_data. a
typedef int (*callback)(int a, int b, int c, int d, CLOSURE_TYPE);
int func1(callback cb, CLOSURE_TYPE)
{
return cb(1, 2, 3, 4, CLOSURE) + 1;
}
int func2(int _p1)
{
DEFINE_CLOSURE
int p1;
int p2;
DEFINE_CLOSURE_END
auto int cb(int a, int b, int c, int d, CLOSURE_TYPE);
int cb(int a, int b, int c, int d, CLOSURE_TYPE)
{
USE_CLOSURE
return _C(p1) + _C(p2) + a + b + c + d;
}
_D(p1) = _p1;
_D(p2) = 1;
return func1(cb, CLOSURE_DATA);
}
--
Best wishes
Bean
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
