Всем привет ... кто разбирается в Cи помогите плиз.
Програмируя под KOS на Си, наткнулся на следующую проблемму :
Мне нужно было отобразить какойнить рисунок, и вот - libJPEG и libPNG которые шли с MenuetLibC(bin pack) (*.lib) без проблем линковались . И всё бы ничего еслибы они не валились в рантайме .
Могу позже выложить лог крэша из борда ... но я думаю он не сильно поможет .
Если кто на это натыкался , то подскажите плиз ,как была решена проблемма. (компиля под винду "тот же код" всё работает и не крэшится!!);
LibC(MenuetLibC) + GCC
Наверное, все дело в том, что Menuet и Kolibri уже несколько лет как не совместимы...
Можно бороться, думаю, пересобрав эти самые библиотеки, используя версию libc для kolibri, которую можно найти на сайте diamond'а
Можно бороться, думаю, пересобрав эти самые библиотеки, используя версию libc для kolibri, которую можно найти на сайте diamond'а
Очень-очень плохая новость для всех, кто пользуется LibC для GCC и MinGW.
Кроме костылявой реализации сигналов, в библиотеке большие проблемы с реализацией crt, а может быть, и чего-то еще.
А именно: некорректно работает передача аргументов программе (argc, argv). Данные функции используются, насколько я знаю, в fceu, shell и возможно других программах (cObj?), не говоря уже про те, которые я пытаюсь портировать.
Временами (по не очень ясным пока причинам) получается скомпилированная программа, в которой argc всегда равен очень большому числу, а обращение к argv[n] приводит к page fault. Подобную проблему можно увидеть, например, в реализации brainfuck для Колибри.
Код, ответственный за разбор параметров, подписан diamond'ом, что очень печально. Боюсь, в ближайшее время он не сможет помочь с исправлением этой ошибки в libc. Поэтому очень большая просьба для всех, кому не безразлична libc и кто использует ее для своих программ: если вы найдете (нашли) ошибку, пожалуйста, расскажите, в чем дело и как ее исправить.
Возможно, мне помог бы исходный код newlib.
Этот код работает:
А этот код не работает:
Кроме костылявой реализации сигналов, в библиотеке большие проблемы с реализацией crt, а может быть, и чего-то еще.
А именно: некорректно работает передача аргументов программе (argc, argv). Данные функции используются, насколько я знаю, в fceu, shell и возможно других программах (cObj?), не говоря уже про те, которые я пытаюсь портировать.
Временами (по не очень ясным пока причинам) получается скомпилированная программа, в которой argc всегда равен очень большому числу, а обращение к argv[n] приводит к page fault. Подобную проблему можно увидеть, например, в реализации brainfuck для Колибри.
Spoiler:
В коде есть проверка на argc>=2, но даже если никаких параметров не передано, argc значительно больше 2, поэтому происходит обращение к argv[1]. И - page fault.Возможно, мне помог бы исходный код newlib.
Spoiler:
Не верится?Этот код работает:
Code: Select all
void main(int argc, char** argv){
int x=argc;
printf ("argc .. %d .. \n", x);
char * fil;
fil=argv[1];
printf ("file .. %s .. \n", fil);}
Code: Select all
void main(int argc, char** argv){
printf ("argc .. %d .. \n", argc);
printf ("file .. %s .. \n", argv[1]);}
Sorcerer
У меня правильно работает. Ты наверное забыл указать размер стека. Для программ с newlib опции линковки: -nostdlib -static -T kos.ld --image-base 0 --stack 0x100000
Стек только резервируется, так что больше чем надо не выделится.
У меня правильно работает. Ты наверное забыл указать размер стека. Для программ с newlib опции линковки: -nostdlib -static -T kos.ld --image-base 0 --stack 0x100000
Стек только резервируется, так что больше чем надо не выделится.
я компилирую mgcc. вечером проверю,спасибо... не думал,что стек не выделяется динамически... как примерно рассчитать достаточный его объем?
Не понял
У моего ld нет опции stack. Это кому такой параметр нужно передавать? Или в menuetlibc это в crt0_coff.asm параметр app_stack (который идет после заголовка MENUET01)?
У моего ld нет опции stack. Это кому такой параметр нужно передавать? Или в menuetlibc это в crt0_coff.asm параметр app_stack (который идет после заголовка MENUET01)?
Если не ошибаюсь, эта опция для mingw32-ld. Или для бинарников в формате PE.
Как-то так.
Как-то так.
Беда у меня нет mingw
Sorcerer
можешь пока mingw не искать. добавление опции --stack 0x100000 в исходник mld и его перекомпилирование не помогло.
можешь пока mingw не искать. добавление опции --stack 0x100000 в исходник mld и его перекомпилирование не помогло.
Sorcerer
Опция --stack толька для сборки с newlibc. Она в coff и рассчитана на mingw или кросскомпилятор если в Linux.
Опция --stack толька для сборки с newlibc. Она в coff и рассчитана на mingw или кросскомпилятор если в Linux.
"Код, ответственный за разбор параметров, подписан diamond'ом, что очень печально. Боюсь, в ближайшее время он не сможет помочь с исправлением этой ошибки в libc." - а что, глюки здесь умел исправлять только diamond? То-то в последнее время никто ничего не исправляет...
P.S. Размер стека в menuetlibc задаётся статически константой в crt0*.asm.
P.S. Размер стека в menuetlibc задаётся статически константой в crt0*.asm.
Сделаем мир лучше!
Программист, написавший код, понимает его скорее всего лучше, чем кто-либо еще, мне кажется.
Размер стека - это app_stack в crt0.asm, и выглядит он как обычно в программах для Колибри на FASM - в конце файла "app_stack:". Действительно ли проблема в этом, или может быть, что нет?
Размер стека - это app_stack в crt0.asm, и выглядит он как обычно в программах для Колибри на FASM - в конце файла "app_stack:". Действительно ли проблема в этом, или может быть, что нет?
Так и было. Кстати, не нашёл исходников menuetlibc на svn. Надо залить. Иначе начнётся путаница с версиями.CleverMouse wrote:а что, глюки здесь умел исправлять только diamond
Да, залить просто необходимо. Но нужно выбрать лучшую версию.Serge wrote:Надо залить. Иначе начнётся путаница с версиями.
Если будет на svn, то и ошибки проще исправлять. Я уже несколько мелких нашёл.
Вообще-то diamond это человек, как и все остальные человеки. Может хватит его пытаться канонизировать? Он еще жив и здоров. Баги исправлял не только он, но поскольку его соображалка работает лучше и быстрее, чем у многих из нас - то так получалось, что он быстрее правил и тащил на себе все. Что собственно и привело к тому что "сгорел" на работе.
Who is online
Users browsing this forum: No registered users and 0 guests