Board.KolibriOS.org

Запускаю в VMWare Player. Получаю "Ошибка: Неподдерживаемая инструкция процессора"

Это в версии из моего предыдущего сообщения или из темы про образ для CC?
Может, дело в march=i486 - какой процессор эмулирует VMWare?

Насчёт эмуляции ничего сказать не могу.
Кроме того в KlbrInWin при запуске без параметров программа падает.

Спасибо за репорты, буду вечером отлаживать.
И всё-таки: о какой версии бинарника идёт речь?

Бинарник - последний в этой теме (Чт авг 18, 2011 11:12 pm).

Albom
Эмулятор давно уже не показатель и не был им с самого начала. Вот если падает и в самой среде Колибри также, то это однозначный показатель. Лучше проверять в Qemu, Bosh, VirtualBox, VMWare в запущенной Колибри. Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе.

Конечно KlbrInWin не является показателем...
Только что потестировал ещё...
В Qemu работает. В VMWare выдаёт указанную ранее ошибку (при помощи @notify).

"причину странного поведения печаталок хотелось бы выяснить." - а что тут выяснять-то? Как пишут в сети, кривой gcc содержит баг, из-за которого поддержка 64-битных целей запрещает нормальное для 32-битных целей выравнивание стека. В результате gcc генерирует кривой код, в котором он не может просто использовать значения argc и argv из стека - как это сделал бы нормальный компилятор, - а вынужден задействовать регистры. Один из регистров в ходе инициализации портится.

Т.е. проблема в использовании именно gcc-4.4, а в gcc-3 все может быть и будет ОК?

Sorcerer, да, с поправкой "gcc-4.4 с поддержкой 64-битной кодогенерации". Версия, собранная на сервере автосборки, такие параметры кушает нормально.
XVilka, под Колибри есть свой отладчик mtdbg, не требующий шаманства с qemu+gdb+бубен_для_поиска_нужной_программы_в_памяти.
Mario, утверждение "Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе." требует доказательств. Я ещё могу поверить в наличие небольших глюков эмулятора при использовании свежих - на тот момент - и редких фич, но этого недостаточно для характеристики "часто". Это кривой код, генерируемый gcc, который по умолчанию не может поверить в существование процессоров без SSE. На таких процессорах с эмуляторами, использующими реальный процессор, будет вылетать. На уровне исходного кода Си искать ошибку бесполезно.

Боже мой, вот такое нужно показывать людям, которые кричат: -ааавно этот ваш ассемблер, вот Си лучше!
Попробую собрать gcc без поддержки 64 бит, и перекомпилировать как минимум lua.

CleverMouse wrote: Mario, утверждение "Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе." требует доказательств. Я ещё могу поверить в наличие небольших глюков эмулятора при использовании свежих - на тот момент - и редких фич, но этого недостаточно для характеристики "часто".

Автор эмулятора сам говорил об этом. Насчет часто не могу ни подтвердить, ни опровергнуть. Когда я разрабатывал используя KlbrInWin, то достаточно часто ловил глюки которые отношения к собственно программе не имели. Для меня часто это раз в 1-2 дня при активной разработке. После того как Евгений перестал обновлять эмулятор я для себя решил, что пользоваться им в дальнейшем как инструментом разработчика не есть правильный путь. Вот собственно все - на этом предлагаю оффтоп не имеющий к Питону отношения закончить. Успехов.

Зачем такие сложности ? -mtune -march

Serge wrote:Зачем такие сложности ? -mtune -march

Jaeger wrote:Добавил march=i486, не помогает.
Всё чудесатее и чудесатее.

???

Значит gcc сейчас делает выравнивание стека независимо от целевой архитектуры. Тем не менее c newlib таких проблем не возникает. Значит это не баг gcc.