Как программа использует стек здесь? - PullRequest
1 голос
/ 23 декабря 2011

Для кода, показанного ниже, если я печатаю адреса, я получаю следующее.

&test_var1 = 0x7fff0067d87c
&barrier (passed argument) = 0x7fff0067d770
&i (passed argument) = 0x7fff0067d77c
&test_var2 = 0x7fff0067d78c

Есть две вещи, которые я здесь не понимаю. Во-первых, я прочитал, что C выдвигает аргументы справа налево, затем, как & i больше & барьер . Зная, что стек увеличивается с более высокого адреса на более низкий, & i должен быть по более низкому адресу. Более того, локальная переменная test_var2 находится по еще большему адресу.

Во-вторых, можно ожидать, что значения & барьер и & test_var1 будут близки друг к другу, но нет, вы видите большую разницу в 268 байтов. Что между ними находится в стеке?

Обратите внимание, что я использую оптимизацию O3. Это из-за этого? Может быть, компилятор сыграл здесь несколько хитростей? Я использую volatile, чтобы убедиться, что каждая переменная находится в стеке и не кэширована в каком-либо регистре.

void some_func()
{
.........
{
  volatile int test_var1 = 0;
}
call_func( i, &barrier );
........
}

void call_func( volatile int i, volatile pthread_barrier* barrier )
{
 volatile int test_var2 = 0;
 ........
}

Ответы [ 2 ]

3 голосов
/ 23 декабря 2011

На x86 стек (используемый, когда f () вызывает g ()) растет вниз.

В любом случае компилятор упорядочивает var / s для определенного вызова в зависимости от реализации.

1 голос
/ 23 декабря 2011

Здесь вы делаете кучу предположений, ни одно из которых не является действительно оправданным:

  • Компилятор должен выдвинуть некоторое количество регистров при вызове функции;нет правила, согласно которому они не могут быть между аргументами и локальными переменными.
  • Нет правила, что аргументы должны передаваться в каком-то определенном порядке или в случае, если они вообще находятся в стеке;аргументы также могут передаваться в регистрах.
  • Как память организована в программный стек, зависит от процессора;в архитектуре x86 она увеличивается вниз , а не вверх.
...