🚀 go-pugleaf

On 10.07.2006, Bogdan (bogdro) <bogdan@bogdan.pl> wrote:
>> Zdaję sobie z tego spawę.
>> Z uwag dodatkowych:
>> - brakuje mi opisu, jak łączyć C i assemblera, gdy to assembler jest
>>   głównym językiem (sytuacja odwrotna do wstawek). To już zahacza
>>   o entry points (main i _start), tablicę symboli w kompilatorze
>>   (u mnie: GCC), format ELF, biblioteki statyczne i współdzielone
>>   i o loader ELF-ów
>
>  Łączenie C z asmem jest takie samo, jak asma z C:
> 	nasm -f elf czesc1.asm		# zawiera main()
> 	gcc -o calosc czesc1.o czesc2.c czesc3.c

O właśnie. Dlaczego main(), a nie _start, jak do tej pory? Czytelnik
może się zastanawiać, skąd się brało _start i gdzie się podziało przy
linkowaniu z użyciem gcc.

>  W kursie przeznaczonym dla początkujących wolałbym nie wnikać w
> szczegóły formatu ELF i inne skomplikowane sprawy.
>  Za to oba rodzaje bibliotek są omówione w jednym z mini-kursów.

Widać ominąłem minikursy. Ja tam się przegryzałem przez specyfikację :)

>> - funkcje w języku C mogą zwracać wartości o większym rozmiarze niż 32
>>   bity; taka informacja może być pouczająca, gdy się pokaże, co się
>>   dzieje z danymi o rozmiarze QWORD (EAX + EDX, nie pamiętam w jakiej
>>   kolejności) i z dłuższymi
>
>  Dorobię, nie ma tego za dużo. Tylko muszę się przyjrzeć, jak są
> zwracane struktury. Strzelam, że przez wskaźnik, bo niby jak inaczej?

Z tego co pamiętam, to przez stos. Kiedyś wykonałem prosty teścik:
napisałem funkcję zwracającą strukturę z paru intów i zignorowałem jej
wynik ((void)funkcja();). Program tego nie wytrzymał i segfaultnął.
O ile w przypadku pojedynczej wartości zwracanej do 64 bitów funkcja
wołająca może radośnie wynik zignorować, bo ten mieści się w rejestrach,
o tyle zwracanie czegoś większego wymaga już współpracy funkcji
wołającej.

>> - język C zakłada[*], że niektóre rejestry pozostaną niezmienione po
>>   wywołaniu funkcji, a niektóre mogą się zmieniac swobodnie;
>>   wspomnienie, które rejestry są które może być przydatne
>
>  Zrobię, ale na odwrót. Nie będę mówił, że język C wymaga zachowania
> tylko jakichś tam rejestrów, bo zaraz mi "uczniowie" zaczną pisać
> procedury nie zachowujące modyfikowanych rejestrów (z przyzwyczajenia
> nawet tam, gdzie nie używają C).
>  W kursie powiem za to, które rejestry mogą zostać zmienione przez
> funkcje biblioteki C i że "należy się wystrzegać polegania na ich
> zawartości". Treść dokładnie ta sama, ale o wiele lepiej dydaktycznie
> to brzmi :)

:)

>> Można też pokusić się o programowanie sieciowe, ale linuksowy syscall
>> jakoś niespecjalnie mi odpowiada, a użycie funkcji z glibc koncepcyjnie
>> już nie różni się od normalnego programu w C.
>
>  Do linuksowego syscalla (sys_socketcall) to nawet nigdzie nie mogłem
> wyszukać dokumentacji, a serwer i klient w asm w oparciu o glibc już
> są dawno gotowe w jednym z mini-kursów.

No to faktycznie przeoczyłem minikursy.

>> [*] To oczywiście uproszczenie, bo chodzi o konwencję wołania funkcji
>> używaną w plikach ELF na architekturze x86.
>
>  x86 - tak, ale nie tylko ELF. Tak samo jest w Windows, w DOSowym C
> pewnie też.

Spodziewałem się czegoś takiego. Ja używam tylko Linuksa (choć FreeBSD
powinno mieć taką samą konwencję, bo to chyba specyfikacja ELF wymaga
takich a nie innych zachowań), więc wolałem się trzymać znanych mi
faktów.

>  No i kolejne 4 rzeczy "do zrobienia". Na razie przyhamujmy. Zrób
> sobie listę, a jak uporam się z pracami bieżącymi, to znów sypniesz
> tematami :)

:]

-- 
Szukasz dobrego shella? mail | http://marcinhlybin.com/shell/
Stanislaw Klekot