Python для KolibriOS

...
  • Это в версии из моего предыдущего сообщения или из темы про образ для CC?
    Может, дело в march=i486 - какой процессор эмулирует VMWare?
  • Насчёт эмуляции ничего сказать не могу.
    Кроме того в KlbrInWin при запуске без параметров программа падает.
    Attachments
    ex.png
    ex.png (3.91 KiB)
    Viewed 5898 times
  • Спасибо за репорты, буду вечером отлаживать.
    И всё-таки: о какой версии бинарника идёт речь?
  • Бинарник - последний в этой теме (Чт авг 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 ты часто обрекаешь себя и других на поиск несуществующих ошибок в программе." требует доказательств. Я ещё могу поверить в наличие небольших глюков эмулятора при использовании свежих - на тот момент - и редких фич, но этого недостаточно для характеристики "часто".

    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, который по умолчанию не может поверить в существование процессоров без 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.
  • Who is online

    Users browsing this forum: No registered users and 2 guests