Аллока реализация

реализация alloca на самом деле требует помощи компилятора. Несколько человек здесь говорят, что это столь же легко как:

sub esp, <size>

который является, к сожалению, только половиной изображения. Да, который "выделил бы место на стеке", но существует несколько глюков.

1. если компилятор испустил код, который ссылается на другие переменные относительно esp вместо ebp (типичный, если Вы компилируете без указателя кадра). Затем те ссылки должны быть скорректированы. Даже с указателями кадра, компиляторы иногда делают это.

2. что еще более важно, по определению, место, выделенное с alloca должен быть "освобожден", когда функция выходит.

Большой является точкой № 2. Поскольку Вам нужен компилятор для испускания кода для симметричного добавления <size> кому: esp в каждой точке выхода функции.

Наиболее вероятный случай является предложениями компилятора некоторые intrinsics, которые позволяют устройствам записи библиотеки просить у компилятора необходимую помощь.

Править:

На самом деле, в glibc (реализация GNU libc). Реализация alloca просто это:

#ifdef  __GNUC__
# define __alloca(size) __builtin_alloca (size)
#endif /* GCC.  */

Править:

после размышления об этом требовался бы минимум, которому я верю, будет, чтобы компилятор всегда использовал указатель кадра в любых функциях, который использует alloca, независимо от настроек оптимизации. Это позволило бы всем местным жителям ссылаться через ebp безопасно и очистка кадра была бы обработана путем восстановления указателя кадра на esp.

Править:

Таким образом, я сделал некоторое экспериментирование с вещами как это:

#include <stdlib.h>
#include <string.h>
#include <stdio.h>

#define __alloca(p, N) \
    do { \
        __asm__ __volatile__( \
        "sub %1, %%esp \n" \
        "mov %%esp, %0  \n" \
         : "=m"(p) \
         : "i"(N) \
         : "esp"); \
    } while(0)

int func() {
    char *p;
    __alloca(p, 100);
    memset(p, 0, 100);
    strcpy(p, "hello world\n");
    printf("%s\n", p);
}

int main() {
    func();
}

который, к сожалению, не работает правильно. После анализа блока, произведенного gcc. Кажется, что оптимизация мешает. Проблема, кажется, что, так как оптимизатор компилятора полностью не знает о моем встроенном ассемблерном коде, он имеет привычку к выполнению вещей в неожиданном порядке и все еще ссылке на вещи через esp.

Вот результирующий ASM:

8048454: push   ebp
8048455: mov    ebp,esp
8048457: sub    esp,0x28
804845a: sub    esp,0x64                      ; <- this and the line below are our "alloc"
804845d: mov    DWORD PTR [ebp-0x4],esp
8048460: mov    eax,DWORD PTR [ebp-0x4]
8048463: mov    DWORD PTR [esp+0x8],0x64      ; <- whoops! compiler still referencing via esp
804846b: mov    DWORD PTR [esp+0x4],0x0       ; <- whoops! compiler still referencing via esp
8048473: mov    DWORD PTR [esp],eax           ; <- whoops! compiler still referencing via esp           
8048476: call   8048338 <memset@plt>
804847b: mov    eax,DWORD PTR [ebp-0x4]
804847e: mov    DWORD PTR [esp+0x8],0xd       ; <- whoops! compiler still referencing via esp
8048486: mov    DWORD PTR [esp+0x4],0x80485a8 ; <- whoops! compiler still referencing via esp
804848e: mov    DWORD PTR [esp],eax           ; <- whoops! compiler still referencing via esp
8048491: call   8048358 <memcpy@plt>
8048496: mov    eax,DWORD PTR [ebp-0x4]
8048499: mov    DWORD PTR [esp],eax           ; <- whoops! compiler still referencing via esp
804849c: call   8048368 <puts@plt>
80484a1: leave
80484a2: ret

Как Вы видите, это не настолько просто. К сожалению, я поддерживаю свое исходное утверждение, что Вам нужна помощь компилятора.