Firetheestle: Уже лучше. Ещё пара вопросов:
Первый:
> ...обнуляем регистр bx...увеличиваем регистр bx на единицу, чтобы он не перезаписал одну букву на другую
-- что при этом происходит с регистром bx?
Чтобы понять что сделать я поискал prefix в каталоге debian, нашел его в файлике debian/rules2, нашёл там PF, поискал его, нашёл его в debian/changelog и увидел, что его можно передать через окружение.
Если в binutils нет такого механизма, можно отредактировать debian/rules (если prefix там) или скрипт, который вызывается оттуда для сборки.
> почему сопроцессор должен быть в полтора-два раза медленнее процессора Ckpyt: я не уверен, что должен, и судя по вашим цифрам это не так. По моим судить не стоит, поскольку там существенно разные внутренности циклов.
Если вопрос чисто теоретический, то возможно сопроцессору нужен более длинный пайплайн, но я не знаю никакой конкретики об интеловских микроархитектурах.
> я даже видя пример chown () не могу понять как его в main() реализовать korsamc: может вам тогда с изучения C начать? Что именно непонятно?
Мы не будем за вас писать, максимум -- поможем вам написать самому. Но для этого вам надо прекратить изображать беспомощность.
> Я имел в виду - чем открыть библиотеку .so (ARM или x86), чтобы можно было что-то там понять, и не сойти с ума как в случае с IDA? objdump выложи библиотеку куда-нибудь, оценить масштабы бедствия?
> А гуй для него есть?
Есть, но зачем? тот же эклипс.
> А в эклипсе (+ADT) вот гуй (в перспективе Debug) - это для какого отладчика, вы не в курсе?
Не уверен, что перспектива однозначно идентифицирует отладчик. Когда я разрабатывал в эклипсе на С в этой перспективе торчал gdb.
> Как понять, как библиотека получает JNIEnv?
Я не специалист в java, но вижу следующие три принципиальные возможности:
- как параметр;
- вызовом JNI_CreateJavaVM: похоже, не твой случай;
- вызовом AttachCurrentThread: stackoverflow.com/questions/12900695/how-to-obtain...
По идее тебе нужен специалист по java/JNI.
> И какой именно отладчик использовать в данной не совсем типовой ситуации?
Я бы использовал gdb, потому что я всегда использую gdb.
> Как узанть, какого именно метода.
Я бы делал так:
- понять, как библиотека получает JNIEnv через который она вызывает джавовский код;
- запустить приложение под отладчиком, получить JNIEnv, поставить точку останова на вызовы GetStaticMethodID и GetMethodID
- посмотреть для какого метода их вызывают последними.
> я не умею дизассемблировать библиотеки такие
> У меня есть IDA Pro, я могу ею пройтись по .so
Ну так значит умеешь? Не вводи в заблуждение тех кого просишь тебе помочь.
> сложность в том, что всё слетает в JNI ERROR, вроде бы проблема в отсутствии метода, но какого именно - и вообще никакой отладочной информации - не только не дается, но и клещами не вытащишь
Сложность в том, что ты не даёшь никакой полезной информации в своём вопросе.
Опиши, что происходит, кто кого вызывает, куда ты попадаешь, где ты видишь ошибку.
> Git. Как понять, что уже изучил основы?
> Когда сможешь смержиться в команде из 10 разрабов, когда все разом полезли в один файл.
Нет. Когда поймёшь как организовать исходники так, чтобы не приходилось толпой редактировать один файл.
> как ядро может себя decompress если оно сжато, разве структура и команды там не будет не читабельны для процессора? Vi: давайте я вам расскажу, как проследить цепочку сборки, а вы проследите её и увидите, что именно пакуется и как прикрепляется к распаковщику, ОК?
После сборки в каталоге сборки кроме построенных файлов остаются файлы с таким же именем, но с точкой в начале и с расширением .cmd. Это -- команды, которыми собираются соответствующие файлы. Так, например, заглянув в arch/x86/boot/.bzImage.cmd можно увидеть следующее:
т.е. bzImage делается командой arch/x86/boot/tools/build из нескольких файлов, в том числе arch/x86/boot/vmlinux.bin
Заглянув в arch/x86/boot/.vmlinux.bin.cmd можно увидеть следующее:
т.е. arch/x86/boot/vmlinux.bin делается копированием всех секций, кроме .note и .comment из arch/x86/boot/compressed/vmlinux
Глядя в arch/x86/boot/compressed/.vmlinux.cmd можно увидеть следующее:
Т.е. arch/x86/boot/compressed/vmlinux линкуется из группы объектников. Самый интересный из них -- piggy.o, загляните в piggy.S, там ассемблерная магия по включению архива:
> что за алгоритвы то такие которые уменьшают обьем с 2200 мегабайт до 40 Vi: отрезание отладочной информации даёт основное уменьшение объёма. Дальше обычный gzip, сжимает он примерно в 2 раза.
> А что значит архитектр ? чем связано это и как ограничивается ?
linux работает на 31 процессорной архитектуре. В некоторых из них (например mips) vmlinux выполняет всю нужную инициализацию сам. В других (например ARM) можно собрать ядро для "выполнения на месте" (XIP, eXecute In Place) -- такой образ можно прошить во FLASH и выполнять код прямо оттуда.
x86 нужны костыли потому что один и тот же образ (vmlinux) можно загрузить несколькими разными способами, при этом машина будет в разных состояниях.
Разработчики ядра для x86 решили, что в 32-битный vmlinux удобно будет попадать в следующем состоянии: https://git.kernel.org/cgit/linux/kernel/git/torva...
А в 64-битный -- в следующем: https://git.kernel.org/cgit/linux/kernel/git/torva...
Задача кода выполняющегося до vmlinux -- привести машину в такое состояние.
Эту задачу мог бы выполнять (и, опять же, для некоторых архитектур выполняет) qemu.
Первый:
> ...обнуляем регистр bx...увеличиваем регистр bx на единицу, чтобы он не перезаписал одну букву на другую
-- что при этом происходит с регистром bx?
Второй: что делает эта команда
> mov s3[bx],di