Python для KolibriOS
-
Запускаю в VMWare Player. Получаю "Ошибка: Неподдерживаемая инструкция процессора"
Это в версии из моего предыдущего сообщения или из темы про образ для CC?
Может, дело в march=i486 - какой процессор эмулирует VMWare?
Может, дело в march=i486 - какой процессор эмулирует VMWare?
Насчёт эмуляции ничего сказать не могу.
Кроме того в KlbrInWin при запуске без параметров программа падает.
Кроме того в KlbrInWin при запуске без параметров программа падает.
- Attachments
-
-
ex.png (3.91 KiB)Viewed 5898 times
-
Спасибо за репорты, буду вечером отлаживать.
И всё-таки: о какой версии бинарника идёт речь?
И всё-таки: о какой версии бинарника идёт речь?
Бинарник - последний в этой теме (Чт авг 18, 2011 11:12 pm).
Albom
Эмулятор давно уже не показатель и не был им с самого начала. Вот если падает и в самой среде Колибри также, то это однозначный показатель. Лучше проверять в Qemu, Bosh, VirtualBox, VMWare в запущенной Колибри. Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе.
Эмулятор давно уже не показатель и не был им с самого начала. Вот если падает и в самой среде Колибри также, то это однозначный показатель. Лучше проверять в Qemu, Bosh, VirtualBox, VMWare в запущенной Колибри. Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе.
Конечно KlbrInWin не является показателем...
Только что потестировал ещё...
В Qemu работает. В VMWare выдаёт указанную ранее ошибку (при помощи @notify).
Только что потестировал ещё...
В 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. На таких процессорах с эмуляторами, использующими реальный процессор, будет вылетать. На уровне исходного кода Си искать ошибку бесполезно.
XVilka, под Колибри есть свой отладчик mtdbg, не требующий шаманства с qemu+gdb+бубен_для_поиска_нужной_программы_в_памяти.
Mario, утверждение "Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе." требует доказательств. Я ещё могу поверить в наличие небольших глюков эмулятора при использовании свежих - на тот момент - и редких фич, но этого недостаточно для характеристики "часто".
Code: Select all
seg000:00000E1A sub esp, 8
seg000:00000E1D movsd xmm0, qword ptr [ecx+0Ch]
seg000:00000E22 movsd [ebp+var_38], xmm0
seg000:00000E27 movsd qword ptr [esp], xmm0
seg000:00000E2C call _fabs
seg000:00000E31 cvttsd2si edi, [ebp+var_38]
Сделаем мир лучше!
Боже мой, вот такое нужно показывать людям, которые кричат: -ааавно этот ваш ассемблер, вот Си лучше!
Попробую собрать gcc без поддержки 64 бит, и перекомпилировать как минимум lua.
Попробую собрать gcc без поддержки 64 бит, и перекомпилировать как минимум lua.
Автор эмулятора сам говорил об этом. Насчет часто не могу ни подтвердить, ни опровергнуть. Когда я разрабатывал используя KlbrInWin, то достаточно часто ловил глюки которые отношения к собственно программе не имели. Для меня часто это раз в 1-2 дня при активной разработке. После того как Евгений перестал обновлять эмулятор я для себя решил, что пользоваться им в дальнейшем как инструментом разработчика не есть правильный путь. Вот собственно все - на этом предлагаю оффтоп не имеющий к Питону отношения закончить. Успехов.CleverMouse wrote: Mario, утверждение "Используя исключительно KlbrInWin ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе." требует доказательств. Я ещё могу поверить в наличие небольших глюков эмулятора при использовании свежих - на тот момент - и редких фич, но этого недостаточно для характеристики "часто".
Зачем такие сложности ? -mtune -march
Serge wrote:Зачем такие сложности ? -mtune -march
???Jaeger wrote:Добавил march=i486, не помогает.
Всё чудесатее и чудесатее.
Значит gcc сейчас делает выравнивание стека независимо от целевой архитектуры. Тем не менее c newlib таких проблем не возникает. Значит это не баг gcc.
Who is online
Users browsing this forum: No registered users and 2 guests