Адрес локальной переменной дает неверный адрес

dominators.c

HashTable ComputeDominanceFrontier (struct Function *function)
^^^^^^^^^

dominators.h

void ComputeDominanceFrontier (struct Function *function);
^^^^

Упс.

Функция ComputeDominanceFrontier вызывается из main.c, которая включает dominators.h, поэтому вызывающая сторона думает, что она возвращает void. Но согласно определению в dominators.c, на самом деле оно возвращает HashTable. Это несоответствие является причиной сбоя, как описано ниже.

Компилятор этого не улавливает, потому что вы не включили dominators.h в dominators.c, поэтому при компиляции dominators.c он понятия не имел, что какой-то другой исходный файл видел конфликтующее объявление. По этой причине, когда заголовок объявляет глобальную функцию, вы всегда должны убедиться, что заголовок включен в исходный файл, определяющий функцию. Вы можете помочь обеспечить это с помощью -Wmissing-prototypes, который выдает предупреждение всякий раз, когда глобальная функция определена без предварительного объявления. См. Предупреждение компилятора для функции, определенной без прототипа в области видимости?

Происходит следующее: на Arm64, как и на многих других платформах, когда функция возвращает тип struct, который не может быть возвращен в регистре, он возвращается по «скрытой ссылке»: вызывающая сторона выделяет место для возвращаемого значения и передает дополнительный скрытый аргумент с адресом этого пространства. В Arm64 дополнительный аргумент передается в регистр x8. Затем вызываемая функция отвечает за копирование возвращаемого значения в это пространство.

В этом случае, поскольку main не знал, что ComputeDominanceFrontier возвращает тип struct, он не выделил такое пространство и оставил x8, содержащий мусор (в вашем случае его значение оказалось 1).

При наивной компиляции вы ожидаете увидеть сбой в конце функции, когда dominance_frontier копируется из стека в фиктивный адрес возвращаемого значения. И похоже, что именно это вы видели в своем тесте Ubuntu (в котором, позвольте угадаю, вместо clang использовался gcc?).

Однако компилятор может оптимизировать это: вместо использования пространства стека для dominance_frontier используйте пространство возвращаемого значения, выделенное вызывающей стороной. Тогда нам не нужно копировать эти данные перед возвратом, поскольку они были заполнены «на месте». Похоже, что clang выполняет эту оптимизацию, даже когда оптимизация «выключена». Таким образом, dominance_frontier на самом деле не живет в фрейме стека ComputeDominanceFrontier, и &dominance_frontier является не адресом стека, а скорее адресом возвращаемого значения, переданным вызывающей стороной, что в данном случае является мусором.

Из публикуемого вами кода (никакого кода, кроме снимков экрана отладчика) можно сделать вывод, что вы используете:

I'm running into a bug in my code where the address of a local stack variable is invalid. I've been trying to debug this with lldb.

In the lldb prompt below, you can see that &dominance_frontier gives the address 0x0000000000000001 which then causes a SIGSEGV on hash_table_init call line 121. However &dominator_tree_adj, gives a valid address. I'm completely baffled as to why this might be the case.

Process 70998 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x0000000100006fd0 ir`ComputeDominanceFrontier(function=0x00006000030f8000) at dominators.c:121:9
   111          struct Array postorder_traversal = postorder (function->entry_basic_block);
   112          struct DFAConfiguration config = DominatorDFAConfiguration (function);
   113          struct DFAResult result = run_DFA (&config, function);
   114  
   115          HashTable dominator_tree_adj = ComputeDominatorTree (function, &result);
   116          printf("%p\n", &dominator_tree_adj);
   117          HashTable dominance_frontier;
   118          printf("%ld\n", sizeof(dominance_frontier));
   119  
   120  
-> 121          hash_table_init (&dominance_frontier);
   122          // Compute the transpose graph from the dominator tree adjacency list
   123          // Each node is guaranteed to have only one direct predecessor, since
   124          // each node can only have one immediate dominator. We will need this
   125          // in the DF algorithm below
   126          HashTable dominator_tree_transpose;
   127          hash_table_init (&dominator_tree_transpose);
   128  
   129          struct HashTableEntry *entry;
   130      

в строке 117 у вас есть

HashTable dominance_frontier;

это переменная, представляющая структуру HashTable, которую вы никогда не инициализируете. Всем остальным процедурам требуется указатель на переменную HashTable, которая не была инициализирована. Я не знаю, почему вы не инициализируете структуру, но передача адреса будет мало или вообще не поможет, потому что все эти функции, похоже, требуют от вас вызова hash_table_create для первоначального создания правильного содержимого структуры.

Вероятно, ваш код должен был быть

    HashTable *dominator_tree_transpose = hash_table_create(number_of_hash_entries);
    hash_table_init(dominator_tree_transpose);

но поскольку вы не предоставили исходный код, я не могу дальше гадать. Я не верю, что вы можете вызвать hash_table_init(), передав ему адрес ОБЪЕКТА. Но я могу ошибаться. В следующий раз опубликуйте исходный код... не сеанс отладки. Включите полное определение типа HashTable, функций hash_table_create() и hash_table_init(), поскольку использование обеих функций не может быть выведено из опубликованного кода.

Примечание. Я публикую это как ответ, потому что это, по-видимому, является причиной неудачи. Но из приведенных фрагментов это недостаточно ясно.