Спасибо, но список точно не исчерпывающий.
the underlying system calls were renamed in kernel 2.6: pread() became pread64(), and pwrite() became pwrite64().
Не поможет( первым делом на ум пришло
Кто знает хранятся ли где-то старые образы ядер?
776da12837c58dc64bb55af4cfc8820d
Вот придумай где подпихнуть твоего человека-Кларка посередине.
добавить в вопрос описание того, как ты пытался диагностировать и решить проблему
ок, добавлю, конечно,
uefi_call_wrapper не сохраняет регистры, а код в __scankeys хранит данные в rbx и rcx. Твоя непосредственная проблема именно в этом, проверяется элементарным добавлением push rbx ; push rcx в начало макроса uefi_call_wrapper и pop rcx ; pop rbx в конец.
Только усложняет код компилятора, разве нет?
Просто не понимаю зачем
Марат Нагаев, рукалицо ): Они обе предоставляют то, что определено стандартами: стандартом языка C, POSIX, SUS, и многими другими. Это их интерфейс с пользователями. И glibc и musl обе предоставляют pread и pwrite, потому что они определены стандартом POSIX.
Интерфейс с ядром у libc с другой стороны, от пользователей он скрыт, в этом смысл libc -- скрывать интерфейс с ядром. Когда ты собираешь libc ты делаешь это используя заголовочные файлы ядра. Не любая комбинация версии libc и версии ядра соберётся. И не любая комбинация будет использовать один и тот же системный вызов для реализации функций libc.