Колибри PE

Kernel architecture questions
  • Присоединяюсь к Атауальпа, где взять бинарник и как собрать бинарник самому, если можно развернутый ответ ) а то на svn несколько лишних скриптов для компиляции которые к PE отношения не имеют.
  • Для сборки нужны migw gcc (я компилирую gcc 4.2.1) fasm, binutils , make и 7z если нужна упаковка в .gz. Сборка простая - открывается консоль cmd и в ней выполняется make. Или простой батник
    @erase lang.inc
    @echo lang fix ru >lang.inc
    @make
    @pause
    если все нормально то получится примерно такой лог

    Code: Select all

    as  -o bin/export.obj core/export.asm 
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/init.obj core/init.c
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/mm.obj core/mm.c
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/slab.obj core/slab.c
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/heap.obj core/heap.c
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/dll.obj core/dll.c
    gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/spinlock.obj core/spinlock.c
    fasm.exe boot/boot.asm bin/boot/boot.obj
    flat assembler  version 1.67.15  (1373667 kilobytes memory)
    3 passes, 7240 bytes.
    fasm.exe boot/start.asm bin/boot/start.obj
    flat assembler  version 1.67.15  (1373667 kilobytes memory)
    4 passes, 851 bytes.
    ld -shared -s -Map kernel.map --image-base 0x100000 --file-alignment 32  -T ld.x -o kernel.mnt kernel.obj bin/export.obj bin/init.obj bin/mm.obj bin/slab.obj bin/heap.obj bin/dll.obj bin/spinlock.obj bin/boot/boot.obj bin/boot/start.obj
    7z a -tgzip kernel.gz kernel.mnt   
    
    7-Zip 4.42  Copyright (c) 1999-2006 Igor Pavlov  2006-05-14
    
    Scanning
    
    Updating archive kernel.gz
    
    Compressing  kernel.mnt
    
    Everything is Ok
    Ядро может выводить отладочный лог в COM1. Это очень удобно если запускать в эмуляторе. Для этого надо открыть makefile и добавить -DCONFIG_DEBUG в строку "CFLAGS =" и перекомпилировать ядро. Для запуска в qemu указать ключ -serial file:путь_к_лог_файлу. Для bochs отредактировать строку в bochsrc.txt "com1: enabled=1, mode=file, dev=путь_к_лог_файлу". На реальном железе такое ядро будет грузиться очень медлено потому что вывод в СОМ занимает много времени.

    P.S. Я выложу новую сборку когда доделаю загрузку PE программ. Примерно через неделю.
  • Жду с нетерпением.
    Загрузка DLL будет реализована?

    ..bw
  • Сейчас этим занимаюсь. PE программы и расшаренные DLL с автоматической линковкой при загрузке.
  • Ядро может выводить отладочный лог в COM1
    Какие параметры порта?
  • 8 бит, остальное по дефолту. Я использовал только в эмуляторах им всё равно. На железе наверное надо ставить 115200 чтобы быстрее работало
  • Сделал загрузку ДЛЛ.

    Пока все длл-ки локальны и не могут импортировать сами, но это пока.
    Здесь свежая превьюшка.
    /rd/1/testcon2.kpe портированный пример работы с консолью. Здесь отладочное ядро (нет оно не зависло. Просто долго, долго, очень долго и старательно пишет всё в сом1).
    Attachments
    console.7z (16.99 KiB)
    исходники портированной консоли
    Downloaded 346 times
  • Какие есть условия для запуска PE EXE? ImageBase, например, должен быть равен нулю? Если он будет выставлен в 0x400000 то это приведет к перерасходу памяти (первые 4Mb будут зарезервированны для удовлетворения смещения секций на ImageBase)?
    DLL локальны (не понял :-) ? Т.е. таблицы импорта в них игнорируются и зависимости для таких DLL разрешены не будут?

    ..bw
    Last edited by bw on Wed Nov 05, 2008 12:35 pm, edited 1 time in total.
  • Базы программ и длл должны быть 0. Для фасма это не проблема
    format PE GUI at 0
    format PE GUI 4.0 DLL at 0
    Перерасхода памяти не будет. Образ неправильно скомпонуется и вылетит со страничной ошибкой. Длл локальны в том смысле что находятся в пространстве процесса. Если десять программ ссылаются на одну длл она будет загружена десять раз. Таблицы импорта в длл игноруруется. Загрузчик не различает длл и приложения и может запустить длл как программу. Всё это будет исправлено, а пока так.

    Путь к программе и командная строка передаются через стек. Я взял за основу System V ABI. После загрузки приложения стек выглядит так

    Code: Select all

    typedef struct
    {
        int     argc;       /*  always 2                                */
        char   *path;       /*  argv[0]   program path                  */
        char   *cmdline;    /*  argv[1]   command  line. May be null    */
        u32_t   sep1;       /*  separator.  must be zero                */
        char   *env;        /*  single environment string               */
        u32_t   sep2;       /*  separator.  must be zero                */
        auxv_t  aux[1];     /*  aux. AT_NULL for now                    */
    }exec_stack_t;
    [esp] = argc
    [esp+4] = path и т.д

    Стек расположен в вершине адресного пространства процесса. Пока стек жёстко ограничен одной страницей.
  • Разделил тему.
    in code we trust
  • > Базы программ и длл должны быть 0.
    Странное решение, надеюсь в скором времени ты исправишь этот момент. Хотелось бы иметь возможность загружать существующие (под винду) библиотеки без предварительного изменения в них image base и соответствующей релокации. Конечно, для выполнения зависимостей некоторых DLL придется поработать мозгом и написать частичные реализации kernel32.dll и т.п. Например, первым делом, я хочу поработать над xvid.dll. У этой библиотеки существуют, вполне реализуемые, зависимости от kernel32.dll и user32.dll.

    ..bw
  • Базу для длл я поправлю. Насчёт Win DLL я не столь оптимистичен. Существующий загрузчик не сможет их правильно загрузить. И правильная реализация функций из win api дело довольно нудное. Мне кажется быстрее портировать и скомпилировать их под Колибри.
  • > Существующий загрузчик не сможет их правильно загрузить.
    А в чем может возникнуть сложность? Удручающая новость, если честно, я сильно расчитывал на это.

    > И правильная реализация функций из win api дело довольно нудное.
    Это конечно так. Но я не ставлю перед собой цель реализовать весь API, а только по мере необходимости.

    > Мне кажется быстрее портировать и скомпилировать их под Колибри.
    Собирать виндовый код из под Linux то еще приключение, особенно сишный код паскалисту :-). Мои начинания с медиаплеером потому и заглохли. Существующих реализация libc окозалось недостаточно, ни для xvid, ни тем более для ffmpeg. Писать свои заглушки для недостающих имен на си я не могу из-за недостатояного опыта разработки на этом языке, а на pascal'е это довольно проблематичная задача, хотя бы потому, что определение функций типа cdecl реализовано слабовато (нельзя работать с "..." в параметрах).

    p.s. К тому же исходники не всегда доступны ;-).

    ..bw
  • Действительно, наверное благодаря улучшеным иконкам (а может и чему-то ещё)), образ грузится значительно быстрее.
    Из хаоса в космос
  • Who is online

    Users browsing this forum: No registered users and 5 guests