Неопределенная ссылка на main () из-за несоответствия сигнатур при компиляции с использованием Clang-6.0 с -ffreestanding - PullRequest
0 голосов
/ 15 октября 2018

Я разрабатываю ядро ​​ОС как хобби, и у меня уже есть библиотека, которая заменяет стандартную библиотеку как в размещенной, так и в автономной среде.Естественно, это обеспечивает точку входа, которая выполняет необходимые настройки и вызывает main().

. В размещенной среде кажется, что не имеет значения, подписи декларации main() и фактические main() определение не совсем совпадает.Однако после добавления флага компиляции -ffreestanding компоновщик больше не может разрешить такую ​​ссылку.См. Минимальный пример ниже:

start.cpp

int main(int argc, char *argv[], char *envp[]);

extern "C" void _start()
{
    main(0, nullptr, nullptr);
}

main.cpp

int main()
{
    return 0;
}

Командная строка:

clang++-6.0 -nostdlib -ffreestanding start.cpp main.cpp

Кажется, что это поведение специфично для Clang, поскольку GCC 7.3.0 успешно компилирует этот пример.

Мой вопрос заключается в том, как приведенный выше пример разрешен и работает в целом, иПроблема, с которой я сталкиваюсь, - это ошибка Clang.


Обновление 1:

Оказалось, что решением этой проблемы является добавление __attribute__((weak)) кдекларация main().Однако было бы неплохо, если бы кто-то мог объяснить более подробно, как это обычно работает с main().

Обновление 2:

Видимо пометив main() какслабый символ делает возможным соединение без main() вообще, что явно не так, как обычно (учитывая все другие «неопределенные ссылки на основные» вопросы по SO).Поэтому, если main() обычно не является слабым символом, как он на самом деле работает?

Обновление 3:

Оказывается, что слабый символ вообще не является решениемпотому что при использовании с -ffreestanding он скрывает только тот факт, что int main(int argc, char *argv[], char *envp[]) никогда не разрешается и фактический int main() вообще не вызывается из _start().В размещенной среде, однако это все еще называют как обычно.Это все больше и больше похоже на ошибку Clang.

...