ARM, RISC-V контроллеры

Никак? Обычно такие функции, которые не может выполнить аппаратура, реализуются в libgcc (см. по ссылке). Но в EABI (application binary interface) для ARM предусмотрено, что есть функция __aeabi_uldivmod, которая может быть реализована библиотекой... но видимо никак не реализована, а gcc вместо __udivdi3 (худо-бедно реализованной для обобщённого случая) подсовывает __aeabi_uldivmod (которая якобы именно на ARM должна быть хорошо реализована). В сущности проблема в не 

соответствующей ABI runtime-библиотеке.

Как компилятор формирует код:

https://godbolt.org/z/1P4Ys3

(в итоге реализацию __aeabi_uldivmod должна предоставить библиотека...)

В ABI функция __aeabi_uldivmod фигурирует (раздел 4.2, страница 19):

IHI0043D_rtabi.pdf

Функции реализуемые libgcc:

https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html

(обращаю внимание, прототипы в документации написаны неправильно: xxxsi3 -- инты, xxxdi3 -- 64-бита, xxxti3 -- 128-бит видимо)

Реализацию как ни странно можно подсмотреть в том же libgcc:

https://code.woboq.org/gcc/libgcc/config/tilepro/softdivide.c.html#__udivdi3_inline

Ещё вариант:

https://www.ida.liu.se/~TDIU25/pintos/src/lib/arithmetic.c

(там ссылка на Hackers Delight, не рабочая...)

А надо мной помнится издевались когда я спрашивал как распечатывать 64-битное число...

http://caxapa.ru/869150

Возвращаясь к теме, можно заставить gcc не использовать функции из EABI, если дать опцию -mabi=apcs-gnu или -mabi=-atpcs. Тогда вместо __aeabi_uldivmod генерируется вызов __udivdi3, а последняя реализована в libgcc. Насколько это (не)корректно я не знаю. Был бы рад, если бы кто пояснил.

Процитирую:

The EABI (Embedded ABI) is newer and supports additional features, faster software floating point operations, and Thumb interworking, but is only compatible with ARMv4t and newer cores. The EABI has sub-ABIs of: aapcs-linux and aapcs. aapcs-linux has standard Linux 4 byte enums while aapcs has variable length enums. aapcs-linux is recommended over aapcs. The OABI (old ABI) is called apcs-gnu and supports ARMv4 and older cores. Generally the OABI is not used by modern ARM processors.

По ссылке подробнее:

http://pwntoolssoc.blogspot.com/2015/06/oabi-and-eabi-notes.html

Как я понял, возврат в OABI означает проблемы с FPU, прошу меня уточнить... С EABI архитектура делится на две: armel и armhf. В первой software float point (сюда, стало быть, попадает большинство контроллеров), во второй наличие FPU подразумевается. В OABI подразумевается наличие FPU или эмуляция со стороны ОС при его отсутствии (чего нет в контроллерах).

Вдогонку, для FPU есть отдельная опция -mfloat-abi и как я понял адекватная альтернатива: -mabi=atpcs (APCS относится к до-Thumbовской эпохе и не актуально в связи с чем). Вопрос, насколько совместимы ATPCS (http://www.soe.uoguelph.ca/webfiles/engg4420/ATPCS.pdf) и AAPCS (https://web.eecs.umich.edu/~prabal/teaching/resources/eecs373/ARM-AAPCS-EABI-v2.08.pdf) дейсвующий по-умолчанию сейчас. В последнем документе на 6 странице расшифровываются все виды аббревиатур ABI, кстати. И пишется, что ATPCS -- предшественник. Я не понял, но кажется совместимость есть. Кстати довод за то, чтоб уметь пересобирать с нужной опцией все библиотеки (включая toolchain) вообще...

Потенциально можно поискать на github библиотеку libeabi для arm и подлинковать к проекту -- тогда с современным EABI начнёт нормально делить (в библиотеке реализации отсутствующих функций). В целом получается тулчейн -- кривая паделка...