Clang смешно крэшится

[vak]

Набрёл на забавную багу на платке RISC-V. Установил clang из пакетов стандартным образом: "sudo apt install clang", все дела. Вызываю clang без параметров, и внезапно:

$ clang
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: clang 
1.	Compilation construction
/usr/lib/riscv64-linux-gnu/libLLVM-11.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x28)[0x3ff17dec08]
Illegal instruction

Проверил несколько других компиляторов: gcc, rustc, golang. Всё пашет как положено, один clang валится как прокажённый. Написал в bugs.llvm.org - говорят, обращайтесь к своим Debian саппортерам, наворотили чего для RISC-V небось. Посоветовали попробовать собрать с исходников.

Ладно, мне нетрудно, запустил сборку. Процесс компиляции неспешный выходит, боюсь, сутки займёт.

Comments

[archaicos]

Там cmake как-то очень медленно делал свою работу и вроде даже совсем и не думал параллелиться, от чего шланг компилировался часы на мощном компе.

[vak]

Собственно cmake тут нормально сработал. После чего я пробовал запустить "make -j2", чтобы даже на одном процессоре слегка быстрее получилось. Хрен там! В какой-то момент компилятор слетает из-за недостатка памяти. Одного гига маловато для двух одновременных компиляций, а своп не подключен.

Просто make (-j1) идёт уже два часа. Пока на 10% продвинулся.

[archaicos]

О да, gcc съест всю память, даже ту, которой нет. Помнится компиляция TF на трёх гигах оперативки с повторяющимся (до успеха) удвоением размера свопа. :)

[x86128]

А есть qemu с виртуальным risc-v чтобы быстрее собирать?

[vak]

Это-то есть. И я подозреваю, что как раз на QEMU-то clang заработает. Но не на реальном железе.

[archaicos]

О! А нет ли у этого железа списка багов с этим багом? А, похоже заюзали инструкции, которые не везде есть.

[vak]

Именно так. Всё-таки иногда программистам надо отвлекаться от QEMU и нюхать реальное железо. :)

[ivanrubilo]

Зачем так изворачиваться если можно кросс-компилировать на жирном AMD Ryzen?

[vak]

Можно, да, но лениво огород городить. Пусть помаленьку пыхтит на самом RISC-V. Уже аж 17%.

[pappadeux]

> вроде даже совсем и не думал параллелиться

так это не его проблема

кто там снизу был?

[archaicos]

Снизу?

[pappadeux]

cmake не является билдером, он - автоконфигуратор

скажем, конфигурировать для make мб проблемой

а сконфигурировать для ниндзи - и все полетит

[archaicos]

Я понимаю, но были какие-то странные тормоза, и я тогда не стал ковырять.

[spamsink]

gdb не предусмотрен, чтобы посмотреть, что там происходит?

[vak]

Он не сильно помогает:

$ gdb -q /usr/bin/clang-11
Reading symbols from /usr/bin/clang-11...
(No debugging symbols found in /usr/bin/clang-11)
(gdb) r
Starting program: /usr/bin/clang-11 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000003ff215b098 in ?? () from /usr/lib/riscv64-linux-gnu/libLLVM-11.so.1

[vak]

На самом деле можно глянуть, на какой инструкции оно рухнуло:

(gdb) x/i 0x0000003ff215b098
=> 0x3ff215b098:	fence.tso

[vak]

The optional FENCE.TSO instruction is encoded as a FENCE instruction with fm=1000, predecessor=RW, and successor=RW. FENCE.TSO orders all load operations in its predecessor set before all memory operations in its successor set, and all store operations in its predecessor set before all store operations in its successor set.This leaves non-AMO store operations in the FENCE.TSO’s predecessor set unordered with non-AMO loads in its successor set.

[ivanrubilo]

А попробуйте ради спортивного интереса хекс-едитором этот тотал стор ордеринг барьер на обычный фенс заменить, заработает, небось.

[ivanrubilo]

А то и вообще на nop.

[vak]

Так там он не один, я боюсь.

[ivanrubilo]

Так автоматизировать же.

[vak]

Не, я дождусь, когда clang соберётся посредством gcc, и там поглядим. Мне не к спеху.

[vak]

И потом, я не думаю, что QEMU будет вертеться быстрее, чем 1GHz родной процессор. Скорее в разы медленнее, но помноженное на несколько процессоров, то на то и выйдет.

[ivanrubilo]

Так кросс-собрать кланг на маке или писи под таргет risc-v который билдит бинари для risc-v, зачем в qemu-то билдить.
llvm с большим скрипом и на не особо слабом писи-то собирается, памяти желательно не меньше 16 гигов.

[dijifi]

Вспомнилось: QEMU бывает быстрее железа!
Были проекты когда первое железо приходило с отмороженным кэшем и только одним ядром и в результате работало медленнее.

[vak]

По моему опыту QEMU фунциклирует в районе 200-300 МГц, а тут в железе аж целый 1ГГц. Но проблема с памятью: одного гигабайта (без свопа) недостаточно. За ночь компиляция clang свалилась, пришлось добавить своп и перезапустить. Пока продолжается, но у меня всё меньше уверенности, что удастся собрать до конца.

[ivanrubilo]

Да, это весьма кисло, что уже что-то современное и не сбилдить на кривой козе.

[dijifi]

компилятор или линкер свалился? Можно попробовать отключать оптимизацию.

[vak]

Ядро вышибло процесс, так как он перестал помещаться в память.

Я добавил пару гигов свопа и запустил компиляцию снова. Пыхтит уже вторые сутки, прогресс 47%.

[ivanrubilo]

Вполне вероятно если эмулируемый таргет не шибко скорострельный, а хост гигагерцы.

[dijifi]

Железяка 1ГГц, симулятор 3.2 ГГц.

Но поскольку кэш выключен, скорость падает на порядок до скорости интерфейса памяти.