Нубский вопрос по системным вызовам в целом

man syscalls, на ассемблере всё проще, прям как в досе было, только int $0x80.

libc

int $0x80.

Ман sysenter sysexit

Они были в досе? о_0 Возможно, что-то упускаю, конечно...

libc. Она подключается автоматически.

Там написано про враперы из libc. Но ведь libc, как я понимаю, это же тулкит языка си, он ведь является не частью системы (или ядра), а частью стороннего средства разработки. Как же быть если я не хочу линковать libc или пользуюсь другим языком программирования?

Другим языком программирования - это каким?
glibc вызывает системные вызовы используя соответствующие инструкции процессора. Раньше через прерывания 'int', теперь через 'syscall'.

man libc. альтернатива - чистый асм, линковку с libc можно отключить в опциях компилятора, но ядро в любом случае написано в том числе и на си и си everywhere.

http://wiki.osdev.org/System_Calls

Все пути приводили только к стандартной библиотеке языка си, и дальше никуда не вели

а что тебя смущает? круто же. Вообще нужно смотреть маны, не все POSIXные и линуховые ф-ии есть именно в libc. Вот, например, в мане к clock_gettime пишут, что нужно линковаться с librt (-lrt, это тоже часть glibc)

Но ведь libc, как я понимаю, это же тулкит языка си, он ведь является не частью системы (или ядра), а частью стороннего средства разработки. Как же быть если я не хочу линковать libc или пользуюсь другим языком программирования?

Си это базовый яп любого юникса и юниксоподобной ОС. Всё так или иначе использует libc

Другим языком программирования - это каким?

Ну я сказать не могу т.к. сам не видел воочию, но должны же быть какие нибудь другие языки и их компиляторы под linux. Опять же говорю по аналогии с win32, там что на паскале что на бейсике и т.п. независимо от средств разработки можно обратиться к kernel32.dll для совершения системного вызова.

какие системные библиотеки нужно присоединить к проекту чтобы можно было совершать системные вызовы.

зачем?

если я не хочу линковать libc

зачем такие извращения?

или пользуюсь другим языком программирования?

за тебя всё сделает компилятор

В общем, glibc для Linux это как kernel32.dll для Windows. Чисто теоретически можно обратиться к ядру минуя эти библиотеки (как в Linux так в Windows) то это лишняя головная боль.
Что касается других языков программирования, всё что я видел - всё использовало glibc.

Ну я сказать не могу т.к. сам не видел воочию, но должны же быть какие нибудь другие языки и их компиляторы под linux.

другие яп либо предоставляют аналоги (биндинги, bindings) стандартных ф-ий (например, в питоне «пакет» os) и/или имеют некое своё API (свои стандартные библиотеки с уникальным интерфейсом) с возможностью вызова нативных ф-ии через FFI (wikipedia.org).

Не знаю как сейчас, но раньше freepascal мог не линковаться с libc и имел свои обертки над системными вызовами.

Ок, позвольте мое резюме из всего здесь мне сказаного, если не прав поправьте. Вот как я понял: у самого линукса (ядра) не существует своей универсальной api-библиотеки, а системные вызовы осуществляются прерываниями или другой asm-инструкцией, а libc - удобная реализация врапер POSIX-API для linux. Так?

Это ровно настолько же правда насколько «у самого windows (ядра) не существует своей универсальной api-библиотеки, а системные вызовы осуществляются прерываниями (int 2e), а kernel32.dll - удобная реализация врапер winapi для windows».

Ты прав. Asm инструкции доступа к ядру документированы, и для них есть соответствующие заголовочные файлы в которые есть соответсвущие asm вызовы прерываний. Тоесть по идее без линкования с libc, но при использовании соответствующих заголовочных файлов можно написать работающее приложение. Например вам будет доступен open, write, но не будет fopen, printf, fprintf

Все, я запутался.

вам будет доступен open, write

Как вызов функции, или макрос превращающийся в asm-инструкции?

Поясняю - я хочу сказать что разницы с виндой нет (а наверняка и с большинством других современных ОС с изоляцией процессов).

Есть ядро, к нему есть низкоуровневый интерфейс (sysenter|int) и есть библиотека (libc|kernel32), которая предоставляет API (posix|winapi) обёртки над ним. В обоих случаях, хочешь - линкуйся с библиотекой и юзай API (независимо от языка), хочешь - дёргай прерывания из ассемблера.

win: app -> libc -> kernel32.dll -> ntdll.dll -> sysenter
nix: app -> libc -> sysenter
Это если вкратце для базовой функциональности, ну а далее под задачу: pthread для тредов, gmp для сложной математики, gtk для гуя etc.

Ясно. Так я и понял, похоже выразился неправильно. Просто смущала буква «c» в libc в то время как kernel32 поставляется самой виндой и не указывает на конкретный язык.

Приблизительно так

Так что из двух?

Точнее я ошибся. Уже через эти хедеры вызывается libc. Раньше был таки 0x80h. Вот пример чистейшего syscall, которому нафиг не сдался libc

#include <unistd.h> 

int main(){
	write(1, "Hello world \n",13);
	return 0;
}

gcc -S main.c

	.file	"main.c"
	.section	.rodata
.LC0:
	.string	"Hello world \n"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$13, %edx
	movl	$.LC0, %esi
	movl	$1, %edi
	call	write
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Gentoo 4.6.3 p1.11, pie-0.5.2) 4.6.3"
	.section	.note.GNU-stack,"",@progbits

Опа, call write. Погуглил, пишут что избавились от syscall напрямую (хотя все еще можно взять и написать), чтобы иметь возможность чуть похимичить в юзерспейсе ради производительности

ничего присоединять не надо. само присоединиться :)

если хотите прямо в ядро, то вот:

/usr/include/i386-linux-gnu/asm/unistd_32.h

какие регистры у конкретного системного выхова, не знаю, даже не знаю. где подсмотреть :)

еще придется отдельно писать для 32 и 64, так как номера различаются ну и регистры соостветственно, так что libc и нечего мудрить

какие системные библиотеки нужно присоединить к проекту чтобы можно было совершать системные вызовы.

Вопрос слишком абстрактен, непонятно, на какую часть отвечать. Надо немного уточнить вопрос-то.

Во-первых, присоединить к какому проекту? Визуалстудия под линукс программы не пишет. :)

Во-вторых, рассмотрим стандартную задачу: надо написать программу, которая запишет в файл 1.txt строку «Hello, LOR». Как будет выглядеть такая программа в win32 и какие библиотеки для этого надо присоединить?

Ответы на эти вопросы помогут мне понять, что же на самом деле надо объяснить. :)

Ты в общем-то и в венде всегда пользовался врапперами, т.к. winapi это тоже си (msvc compiler abi по крайней мере), а не паскаль и не лисп. Другое дело, что винапи включает в себя дофига юзерспейса, что в юниксе идет сторонними либами, например icu или gtk, а также всегда нехило обратно совместим, так что левые врапперы не ломаются.

На юниксе все идет через либси, не надо глубже копать — ее майнтейнеры всегда следят за совместимостью с ядром, условно выражаясь. Все остальные языки либо поддерживают местный аби, либо имеют прослоечные врапперы.

И в паскаль, и в бейсик, про которые ты говоришь, встроена поддержка аби винапи в виде объявления функции с определенными ключевыми словами. Другие бейсики могут этого и не иметь. То есть «независимо от средств разработки» это частое явление, но не обязательное.

Ещё можно посмотреть это: https://github.com/justincormack/ljsyscall

Как же быть если я не хочу линковать libc или пользуюсь другим языком программирования?

Например, Free Pascal (fpc) обходится без libc, насколько я помню. Посмотри, как это сделано там.

gtk для гуя

Ахаха! Смишно пошутил. Хлиб где?

На счет паскаля не знаю, а вот например бейсику VB ненужно никаких аби, он может подключить kernel32.dll. В виндовс код скомпилированный любым компилятором способным подключать динамические библиотеки может спокойно обращаться к винапи.

Кaкой ты толстенький.

Либо толстенький, либо плохо понимаешь что такое аби. В любом случае твой вопрос уже разжеван, а за остальным дуй в гугл/википедию.

Ахаха! Смишно пошутил. Хлиб где?

Понятия не имею, где-то в `pkg-config --cflags --libs gtk+-3.0`, gtk привёл лишь в качестве примера.

а вот например бейсику VB ненужно никаких аби, он может подключить kernel32.dll

Потому, что у него рядом где-то валяется kernel32.lib, в которой всё описано что и где лежит.

В виндовс код скомпилированный любым компилятором способным подключать динамические библиотеки может спокойно обращаться к винапи.

В линуксе, представь себе, тоже. И даже dlopen есть, свой аналог LoadLibrary.

Мои вопросы были проигнорированы, чувствую, это был тупо троллинг. Но сделаю ещё одну попытку...

какие системные библиотеки нужно присоединить к проекту чтобы можно было совершать системные вызовы. Ожидал увидеть нечто аналогичное виндового kernel32.dll

Как это часто бывает, всё дело в терминологии. Что такое «системная библиотека», «системный вызов», что лежит в kernel32.dll?

В комплекте с виндой идёт куча ПОЛЬЗОВАТЕЛЬСКИХ библиотек. Их можно найти в каталогах C:\Windows, C:\Windows\System32 и т.д. Их много, kernel32.dll, user32.dll, comctl32.dll, opengl32.dll — всё это ПОЛЬЗОВАТЕЛЬСКИЕ библиотеки, многие из них можно подключить и вызвать оттуда какую-нибудь функцию. По-настоящему «системные» функции в виндовс хранятся в ядре ntoskrnl.exe, их не подключишь из программы, и для их вызова используется специальная машинная команда (int 2Eh или sysenter).

Теперь в линуксах. В комплекте с линуксом идёт куча пользовательских библиотек. Их все можно найти в подкаталогах /lib и /usr/lib. Их много, libc.so, libreadline.so, libpthread.so, libm.so, libdl.so, libz.so — всё это пользовательские библиотеки, многие из них можно подключить и вызвать оттуда какую-нибудь функцию. По-настоящему системные функции в линукс хранятся в ядре vmlinuz, их не подключишь из программы, и для их вызова используется специальная машинная команда (int 80h или syscall).

Не считая названий — нет никакой разницы. :)

например бейсику VB ненужно никаких аби, он может подключить kernel32.dll. В виндовс код скомпилированный любым компилятором способным подключать динамические библиотеки может спокойно обращаться к винапи.

Да, и в линуксе код, скомпилированный любым компилятором может подключать любые библиотеки. Никакой разницы. :)

Парни, я уже писал что мой вопрос решен и тема закрыта, в чем проблема?

У тебя опять какая-то проблема? Хочешь об этом поговорить?

«системная библиотека»

ПОЛЬЗОВАТЕЛЬСКИХ библиотек

Первый раз встречаю такую терминологию, если бы сталкивался с ней раньше то сделал бы уточнение. Говоря системные библиотеки я имел в виду, если брать к примеру виндовс, как раз kernel32.dll, shell32.dll и т.д. А вопросы я расценил как тролинг, т.к. очень похоже. Поэтому извиняйте.

Пользовательские библиотеки - в том смысле, что код выполняется в пространстве пользователя, а не ядра. Большая часть Windows API реализована вне ядра, также как libc в GNU/Linux. Более того родное API ядра Windows - это Native API, а не Windows API, реализуемое kernel32.dll, user32.dll, advapi32.dll и другими.

Говоря системные библиотеки я имел в виду, если брать к примеру виндовс, как раз kernel32.dll, shell32.dll и т.д.

Да, но где провести границу между «системными» и «несистемными» библиотеками? ;) xvid.dll — системная? Считать системными все, что в system32? А если я туда свою библиотеку положу, она тоже станет системной?

Первый раз встречаю такую терминологию

Когда-то в школах рассказывали, что «операционная система — это невидимая прослойка между программами и оборудованием». После чего школьники смотрели на виндовс, понимали, что никакая она не невидимая, и успешно забывали эту фразу. В винде действительно нет чёткой границы, вон, какой-нибудь csrss, вроде бы, обычный процесс, но стоит его убить, и система уходит в BSOD, потому что это «критический компонент операционной системы».

В линуксе чёткая граница есть. Некоторые даже считают, что слово «линукс» — это только ядро, а остальное — просто программы. Ядро лежит в файле /boot/vmlinuz* (плюс подгружаемые модули в /lib/modules/), и обеспечивает доступ ко всему оборудованию. Добраться до оборудования в обход ядра невозможно.

Так вот, все программы и библиотеки выполняются в «пространстве пользователя» (user space), а ядро и драйвера устройств — в «пространстве ядра» (kernel space). Соответственно, библиотеки предназначенные для выполнения в пространстве пользователя — это пользовательские библиотеки.

Да, но где провести границу между «системными» и «несистемными» библиотеками? ;) xvid.dll — системная? Считать системными все, что в system32? А если я туда свою библиотеку положу, она тоже станет системной?

Как на счет библиотеки поставляемой с системой (по аналогии с системными утилитами)? Ведь говоря «системная утилита», никто не подразумевает что она выполняется в пространстве ядра.

поставляемой с системой

Какой системой? Что значит поставляется вместе? На первом установочном DVD Debian 7.1 есть libpng, считать её системной библиотекой?

Да, но где провести границу между «системными» и «несистемными» библиотеками?

Как на счет библиотеки поставляемой с системой (по аналогии с системными утилитами)?

Тоже всё не так просто. Даже в винде с разными версиями винды поставляются разные библиотеки. И то, что не поставлялось в WinXP SP1 может уже входить в поставку WinXP SP3. Считать ли системной библиотеку, которой раньше не было, а потом появилась? Или наоборот, считать ли системной библиотеку, которая раньше была, а потом её убрали?

В линухах же вообще все библиотеки необязательны. Можно собрать систему без библиотек, только ядро и busybox. Такой линукс будет грузиться, определять устройства, показывать консоль и поддерживать большинство команд, вообще без библиотек. Так иногда делают на всяких роутерах.

К тому же сами библиотеки тоже могут быть разными. В разных виндах shell32.dll может быть на самом деле разной библиотекой, как минимум разных версий. В линуксах же «libc» — это не конкретная библиотека, а общее название библиотек, хранящих в себе стандартные сишные функции, такие как printf, malloc, free. В федоре libc поставляется пакетом glibc (GNU libc), в дебиане eglibc (Embedded GLIBC), а в устройствах, вроде ADSL-модемов, часто используют uClibc. На неё можно глянуть на http://bellard.org/jslinux/ — забавный пример маленького, но настоящего линукса. Работает полностью в браузере, без инета, можно там всё загадить, сделать rm -rf /, а потом обновить страничку и система снова чистая.

Ведь говоря «системная утилита», никто не подразумевает что она выполняется в пространстве ядра.

Я только пытаюсь сказать, что даже в винде понятия «системная библиотека» и «системная утилита» очень размыты. Кому-то покажется, что это «системная утилита», кому-то что она к системе отношения не имеет. А по сути все библиотеки устроены одинаково, и подключаются одинаково, и «системные» и «несистемные», хоть в винде хоть в линухе. Разве что в линухе dllhell-а нет.