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

Question

Я занимаюсь разработкой ядра ОС как хобби, и у меня уже есть библиотека, которая заменяет стандартную библиотеку как в размещенной, так и в автономной среде. Естественно, это обеспечивает точку входа, которая делает необходимые настройки и звонки 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.