Aleksey Ulasevich подготовил (http://stakanov.nm.ru/as/asm_unix_faq.html) русскоязычный FAQ по использованию ассемблера в
юниксоподобныйх ОС.URL: http://stakanov.nm.ru/as/asm_unix_faq.html
Новость: http://www.opennet.me/opennews/art.shtml?num=6478
аж в ностальгические чувства кинуло...
спасибо!
вот такой бы хелп еще по рисковому ассемблеру, а также по переводу х86 на рисковый ) было бы вообще замечательно ))
На wasm есть описание ARM ассемблера.
хотелось бы под PA-RISC =)
а там есть вопрос "нафига нужен ассемблер в юниксе"?
.
на выходе как раз ассемблер.
В который сунуть нос иногда не мешает.
Хорошо. 10nx! :)
Не поперло - провалился самый первый тестовый пример с выводом стороки "Hello, world!" :(
Сделал Copy Paste в Ubuntu 5.04 и запустил. Не пишет строку. Strace выдает следующее:alexey@ubuntun:~/Trash$ strace -f ./tcall
execve("./tcall", ["./tcall"], [/* 32 vars */]) = 0
write(0, NULL, 0) = 0
_exit(0) = ?Почему то вместо строки передается NULL
Первый пример предназначен для FreeBSD, в которой параметры системных вызовов передаются нормальным образом - через стек. В Linux эти параметры передаются через жопу - если их мало, то через регистры, а если много, то через структуру в памяти. Используй код, предназначенный для Linux.
>Первый пример предназначен для FreeBSD, в которой параметры системных вызовов передаются нормальным
>образом - через стек. В Linux эти параметры передаются через жопу
>- если их мало, то через регистры, а если много, то
>через структуру в памяти. Используй код, предназначенный для Linux.нет, это в бзде пареметры через жопу передаються, а в линухе наиболее быстрым способом в каждом случае ищеться оптимальный метод. Докажи обратное.
В FreeBSD обращение к системным вызовам происходит стандартным, для UNIX, способом, что упрощает переносимость.В Linux используются сразу два нестандартных способа - через регистры и, если их не хватает, через структуру в памяти. В первом случае ядру всё равно приходится куда-то переписывать параметры внутри системных вызовов. Ведь регистры, которых не много, нужны для работы, а не для хранения параметров. Во втором случае нужно выделять память под структуру параметров, записывать в ebp её адрес и в конце освобождать эту память. Использование стека упрощает и автоматизирует всё это. Вообще, использование ebp для передачи более пяти параметров появилось только в 2.4.x, как костыль.
Если бы я не знал, что Linux создавался человеком, до этого использовавшим Minix, я бы решил, что всё, что он до этого видел, была лишь DOS, в которой именно так всё и работает.
По слухам Линус просто читать Posix-стандарт поленился в свое время :-)
>По слухам Линус просто читать Posix-стандарт поленился в свое время
>:-)
ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %))))
ЛОЛ
> ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %))))
Студенты, они все такие. Что-либо пытаются читать только за день-два до экзамена. Даже, если имеют конспекты всех лекций.
>> ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %))))
>Студенты, они все такие. Что-либо пытаются читать только за день-два до экзамена.
>Даже, если имеют конспекты всех лекций.афтар, http://voffka.com/archives/affftarrr.jpg
Если ты решил, что POSIX - это просто дока, которую мона скачать и начитаццо досыта - ты ошибаешься. Набор этих стандартов ДЕНЕГ СТОЯТ. И НЕМАЛЫХ ДЕНЕГ.
Торвальдсу их высылали по кускам, кто что имел. И поверь он их не фтопку складывал.
Все отсупления от посикса у Торвальдса аргументированы.
Как например посикс определяет процесс как набор нитей. А в линухе есть группы процессов (соотвествует POSIX процессу) и процессы (они же нити).
Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге.
> Если ты решил, что POSIX - это просто дока, которую мона скачать и начитаццо досыта - ты ошибаешься. Набор этих стандартов ДЕНЕГ СТОЯТ. И НЕМАЛЫХ ДЕНЕГ.
> Торвальдсу их высылали по кускам, кто что имел.
Вот Вам ссылка http://www.unix.org/version3/online.html - вышлите ее Торвальдсу и Ваше имя попадет в историю линукса.
> Все отсупления от посикса у Торвальдса аргументированы.
> Как например посикс определяет процесс как набор нитей. А в линухе есть группы процессов (соотвествует POSIX процессу) и процессы (они же нити).
Не путайте теплое с мягким: posix определяет интерфейс для т.н. user threads (пользовательских нитей), то, что Вы называете группами процессов и процессами линуха, на самом деле является kernel threads (тьфу-ты, procs) и POSIX-ом не регламентируется. Тип связи между ними выражается цифирками 1:1, N:M и т.д. и закладываетя в libpthreads. Времени нет объяснять Вам дальше, что это такое, поройтесь в Google.
> Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге.
В проектировании NPTL упор делался на light weight в ущерб fairness-у шедулинга. По сравнению с, например, NGPT (не буду сравнивать с BSD и соляркой), времена исполнения группы "одинаковых"(если так можно выразится) тредов будет иметь несколько меньшее мат. ожидание при большей дисперсии. Так, что для задач, у которых критично именно максимальное, а не среднее время отклика, NPTL учитывает все не самым полноценным образом.
>Вот Вам ссылка http://www.unix.org/version3/online.html - вышлите ее Торвальдсу и Ваше имя попадет
>в историю линукса.хорошо вам. Оперируете современным положением. А в средине 90-х сильно было поумничать негде... ну и почитать нахаляву. (кста, остальные 8 частей где мона нарыть ? - возможно путаю общее количество разделов посикса, ну а если это все - то все ок, современные торвальсды имеют больше возможностей проявить себя)
>Не путайте теплое с мягким: posix определяет интерфейс для т.н. user threads
>(пользовательских нитей), то, что Вы называете группами процессов и процессами линуха,
>на самом деле является kernel threads (тьфу-ты, procs) и POSIX-ом не
>регламентируется. Тип связи между ними выражается цифирками 1:1, N:M и т.д.
>и закладываетя в libpthreads. Времени нет объяснять Вам дальше, что это
>такое, поройтесь в Google.
писал это по памяти с цытаты Торвальдса. Но суть передал четко.
Хотя, я сам посикс по вопросу не читал.>> Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге.
>В проектировании NPTL упор делался на light weight в ущерб fairness-у шедулинга.
возможно. Не знаю о чем именно и когда говорил Торвальдс. Возможно с тех пор многое изменилось.>По сравнению с, например, NGPT (не буду сравнивать с BSD и
>соляркой), времена исполнения группы "одинаковых"(если так можно выразится) тредов будет иметь
>несколько меньшее мат. ожидание при большей дисперсии.
да, смотрю ты это курил в правильном математическом свете. Я пока недотягиваю (не интересовало именно это пока что)>Так, что для задач,
>у которых критично именно максимальное, а не среднее время отклика, NPTL
>учитывает все не самым полноценным образом.
возможно. Не стремился это проверить.
Лично мне кажется, что способ "регистры и область в памяти" эффективнее. Даже если ядро переписывает данные из регистров куда-то ещё, код для переписывания существует в системе только один раз, а не встречается в каждой программе.Да, регистры действительно нужны для работы. Но так ведь передаваемые параметры тут же включаются в работу! Кстати, на RISC-процессорах с их большим числом регистров это очень выгодно.
Кстати, хочу напомнить, что DOS создавался для работы в очень стеснённых условиях: сначала памяти просто было мало, а потом адресное пространство было ограничено бинароной совместимостью с программами, написанными для реального режима i80*86. Так что ругать какой-то метод только за то, что он использовался в DOS - это всё равно, что ругать военно-тактические приёмы за то, что когда-то они использовались гитлеровцами. Передача параметров через регистры и область в памяти происходила не только в DOS, но и во многих др.операционках того времени.
> способ "регистры и область в памяти" эффективнее.
Возможно и верно в случае прямых вызовов подпрограм, обслуживающих syscall. В реальности вызывается сначала обработчик int80h. - для BSD /usr/src/i386/i386/trap.c, в котором происходят проверки на MP_SAFE и глобальных блокировок, вызовы процедур трассировки syscall-ов, различный отладочный код и еще куча всего. И только после всего этого происходит передача управления самому syscall-у. Регистры так или иначе придется сохранять и восстанавливать. Со стеком тут все проще - для передачи параметров достаточно 1-го вызова copyin (копирования области памяти из user-space в kernel)
> Так что ругать какой-то метод только за то, что он использовался в DOS
Что использовалось в DOS и других "наколенных" ОС того времени трудно вообще назвать методами. Методами это стало уже в линуксе.
> для BSD /usr/src/i386/i386/trap.cУ Вас небольшая опечатка, правильно /usr/src/sys/i386/i386/trap.c
Кстати, есть ли какие-то существенные отличия между вызовами int $0x80 и lcall $7,$0 кроме того, что после lcall $7,$0 нужно делать addl $16,%esp ?
> есть ли какие-то существенные отличия между вызовами int $0x80 и lcall $7,$0
Я не особо авторитетный человек в этом вопросе, но насколько знаю, для софтверных прерываний разницы, кроме скорости исполнения конкретно этих 2-х инструкций, нет. Краем уха где-то слышал, что в SCO применяется именно lcall.
> кроме того, что после lcall $7,$0 нужно делать addl $16,%esp
addl нужно делать не для lcall, а для восстановления указателя стека после возврата из подпрограммы при cdecl стиле передачи параметров. Он компенсирует изменение esp от серии push
Под FBSD6.0 проверил все работает...
Теперь надо написать пример простого файлового вируса на ассемблере, который заражает ELF фалы :-))
Неплохой ресурс по теме, правда BSD-центричный
http://www.int80h.org/bsdasm/
а есть вирусы работающие в линукс или бзде?
есть
>Aleksey Ulasevich подготовил (http://stakanov.nm.ru/as/asm_unix_faq.html) русскоязычный FAQ по использованию ассемблера в
>юниксоподобныйх ОС.
>
>URL: http://stakanov.nm.ru/as/asm_unix_faq.html
>Новость: http://www.opennet.me/opennews/art.shtml?num=6478небольшая поправка к статье: в ответе "как слинковать, запустить..." в 4-ом варианте(для Линукс) надо указывать: ld -s hello-nasm.o(было ".asm") -o hello-nasm
