i i KSEM WETI PG April 28, 2015
i to zbiór narzędzi do budowy i debugowania programów, zarówno prostych aplikacji jak i elementów jądra systemów Linux. Toolchain zawiera: kompilator (GNU compiler), GNU linker GNU assembler GNU debugger narzędzia do manipulacji zbudowanymi plikami binarnymi (np. objdump, objcopy, readelf, strip, nm) glibc - podstawowa biblioteka C w systemach Linux
The Linux Development Process i Oprogramowanie Linux składa się ze względnie dużej liczby elementów, łączonych podczas budowania w zbiór małej liczby plików (wykonywalnych i niewykonywalnych): Pliki te są: pliki binarne aplikacji biblioteki (resources) dokumentacja dane dla systemu kontroli wersji (source code management, SCM) spakowane w opublikowany pakiet dla konkretnej dystrybucji automatycznie zainstalowane na maszynie docelowej (z pominięciem etapu pakowania i instalacji pakietu)
The Linux Development Process i Oprogramowanie Linux dostępne jest w dwóch formach: archiwa źródeł (tarball); standardowy format to.tar.gz lub.tar.bz2. Rozpakowanie: tar xvfj toolchains.tar.bz2 lub: tar xvfz toolchains.tar.gz system kontroli wersji (SCM); SCM automatyzuje proces pobierania źródeł, nadąża za zmianami oprogramowania, pobiera niezbędne patche.
Konfiguracja lokalnego środowiska Pliki README i INSTALL opisują standardowy proces budowy programu, obejmujący m.in. konfigurację lokalnego środowiska różne platformy sprzętowe mogą mieć specyficzne ograniczenia (np. adresowanie pamięci little-endian lub big-endian), różne dystrybucje Linuxa mogą mieć różne wersje narzędzi i bibliotek systemowych. Ponadto plik INSTALL powinien definiować sposób instalacji i deinstalacji programu, wraz z przykładami. GNU Autoconf - narzędzie konfiguracji lokalnego środowiska w systemach UNIX. Skrypt configure automatycznie sprawdza, czy w systemie zainstalowane są narzędzia (i jakie ich wersje) do budowy programu:./configure [OPTION]... [VAR=VALUE]... Na przykład:./configure help i
Konfiguracja lokalnego środowiska- GNU Make Większość oprogramowania Linux jest budowana przy użyciu narzędzia GNU make. Program ten czyta skrypt Makefile (lub makefile), który opisuje: zależności pomiędzy plikami źródłowymi i plikami wynikowymi, sposób tworzenia plików wynikowych z plików źródłowych. Przykład (plik źródeł: hello.c): i $ make $./hello Hello, World! Makefile może być generowany automatycznie w przypadku przenośnego oprogramowania przewidzianego do pracy na różnych platformach. Automatyczny generator makefile identyfikuje wówczas dostepne narzędzia GNU i od nich uzależnia zawartosć pliku dla GNU Make (tak jest np. w przypadku narzędzi do kompilacji skrośnej).
Konfiguracja lokalnego środowiska- GNU Make Plik Makefile składa się głównie z reguł. Reguła ma następującą budowę: i CEL: SKADNIKI KOMENDA gdzie CEL to nazwa pliku docelowego, który jest tworzony z plików wymienionych jako SKŁADNIKI, zaś KOMENDA podaje komendę, która tworzy plik docelowy CEL z plików składowych SKŁADNIKI Przykład reguły: hello: hello.c aux.c gcc hello.c aux.c o hello Reguła ta określa sposób tworzenia pliku wykonywalnego hello z plików hello.c i aux.c Przed komendą musi obowiązkowo wystąpić znak tabulacji.
Narzędzia i Narzędzia automatycznie: usprawniają powtarzalne cykle kompilacji zapewniają powtarzalność procesu kompilacji, eliminując możliwość popełnienia błędu czynią proces kompilacji (budowy) programu możliwie najprostszym.
GNU Compiler Collection GNU Compiler Collection (GNU C Compiler): 1987: Richard Stallman, założyciel GNU Project, postanowił opracować kompilator, który spełniałby wymagania wolnego oprogramowania (Free Software). kompilator GNU C szybko stał się popularny wśrod programistów wolnego oprogramowania ze względu na swoją przenośność. Dziś GCC obsługuje różne języki programowania: C i C++, Ada, Fortran, Objective C, Java. Jądra systemów Linux napisane są w języku C i skompilowane za pomocą GCC. GCC współpracuje z procesorami o różnych architekturach: Intel IA32 ("x86"). AMD64, SPARC POWER/PowerPC oraz rosnącą liczbą procesorów wyspecjalizowanych. i If it s commercially available, GCC can probably compile code for it!
Kompilacja pojedynczego pliku Proces budowy programu: compile assembly link i Kompilator: tłumaczy kod programu na język maszynowy (specificzny dla danej rodziny procesorów) Assembler: tłumaczy skompilowane źródło na binarną reprezentację kodu maszynowego. nadaje każdej instrukcji maszynowej adres pamięci (ale nie bezwzględny, raczej symbolicznie lub jako przesunięcie). tworzy listę wszystkich nierozwiązanych referencji, które prawdopodobnie zdefiniowane są w innych plikach programu Linker: łączy kod z plików wygenerowanych przez assembler (object code) w tzw. plik-kontener, który może być załadowany do pamięci i wykonany na danej platformie sprzętowej.
Program w pamięci i pamięć stos (adresy powrotu i zmienne lokalne) sterta (zmienne dynamiczne) zmienne statyczne program wysoki adres niski adres
Kompilacja pojedynczego pliku i GCC nie potrafi zbudować wykonywalnego pliku programu, tłumaczy jedynie kod programu na język maszynowy. Domyślnie GCC wykonuje wszystkie kroki potrzebne do zbudowania wykonywalnego pliku binarnego, jednak sam dokonuje jedynie kompilacji. Assembler i Linker to osobne narzędzia, z którymi komunikuje się kompilator. Zwyczajowo plik wykonywalny dostaje nazwę a.out, chyba że użytkownik zdefiniuje ją inaczej za pomocą opcji -o kompilatora gcc.
Kompilacja jednego źródła C i Przykład "Hello World" kod źródłowy: / Embedded Systems Programming Hello World / #include <stdio.h> #include <stdlib.h> int main(int argc, char argv) { printf("hello, World!\n"); return(0); } kompilacja: $ gcc o hello hello.c test: $./hello Hello, World!
Kompilacja wielu źródeł C i GNU linker potrafi łączyć ze sobą kilka plików objektów.o w jeden plik wykonywalny. Przykład: message.c: #include <stdio.h> void goodbye_world(void) { printf("goodbye, World!\n"); } Kompilacja message.c: gcc c message.c Sterownik (driver) GCC woła swój wewnętrzny kompilator, przetwarza kod źródłowy na język maszynowy i przekazuje go na wejście zewnętrznego assemblera. Assembler tworzy plik z rozszerzeniem.o, który może być połączony przez GNU linker z innymi plikami.o.
Kompilacja wielu źródeł C main.c: #include <stdlib.h> void goodbye_world(void); int main(int argc, char argv) { goodbye_world(); return(0); } Kompilacja: gcc c main.c Linkowanie: gcc o goodbye message.o main.o Kompilacja i linkowanie w jednym poleceniu: gcc o goodbye message.c main.c Uruchomienie programu:./goodbye Goodbye, World! i
Biblioteki zewnętrzne, GLIBC Niemal każda aplikacja Liux używa biblioteki GLIBC (biblioteka GNU C) podstawowe operacje wejścia/wyjścia (np. zamknięcie programu) cienka wartwa między aplikacją a jądrem Linuxa; implementacja podstawowych procedur, które byłyby bardziej kosztowne (złożone), gdyby były w jądrze. GCC zakłada, że GLIBC jest domyślnie dodawana do programu podczas etapu linkowania. Mimo to do źródeł programu należy dodać pliki nagłówkowe standardowych bibliotek Przykład: i #include <stdio.h> #include <stdlib.h> #include <math.h> // system math library; part of GLIBC but not automatically inluded int main(int argc, char argv) {... } Kompilacja i linkowanie: gcc o trig lm trig.c opcja -lm powoduje, że GCC przeszukuje bibliotekę matematyczną libm
Biblioteki statyczne a współdzielone i Biblioteki statyczne (static) - podczas kompilacji programu kod biblioteki statycznej jest umieszczany w wynikowym pliku binarnym; każda funkcja ma tyle kopii, ile jest programów, które z niej korzystają. Biblioteki współdzielone (shared) - tylko jedna wersja każdej funkcji współdzielona między aplikacjami; jest to możliwe dzięki pamięci wirtualnej - kilka niezależnych aplikacji ma bezpieczny dostęp do tego samego obszaru pamięci.
Biblioteki statyczne a współdzielone i Biblioteki współdzielone redukują rozmiar pliku wynikowego Jeśli biblioteka jest współdzielona przez wiele różnych programów jednocześnie, pozostaje w pamięci i jest natychmiast dostępna. Biblioteka współdzielona powinna być zbudowana tak, by jej działanie było niezależne od miejsca w pamięci, do którego została załadowana: gcc fpic c message.c Flaga PIC informuje GCC, by w kodzie maszynowym programu nie umieszczał odwołań do adresów pamięci. Utworzenie biblioteki współdzielonej: (plik wyjściowy: libmessage.so): gcc shared o libmessage.so message.o
Biblioteki statyczne a współdzielone i Użycie biblioteki współdzielonej: gcc o goodbye lmessage L. main.o GCC informuje linkera, że ma połączyć kod pliku main.o z biblioteką libmessage.so. flaga -L oznacza, że biblioteki mogą znajdować się w bieżącym katalogu. Własna biblioteka współdzielona może być używana tak jak dostarczana wraz z dystrybucją Linux, pod warnkiem, że znajduje się w odpowiednim katalogu (np. /usr/lib/) ld-linux - dynamiczny linker; automatycznie uruchamiany, gdy uruchamiana jest aplikacja używająca bibliotek współdzielonych. Poszukuje ich w katalogu /lib i /usr/lib (te domyślne ścieżki mogą być zmienione w pliku konfiguracyjnym /etc/ld.so.conf.
Biblioteki statyczne a współdzielone ldd - przeszukuje domyślne systemowe ścieżki bibliotek współdzielonych i wypisuje wersje tych bibliotek, używane przez program: i ldd goodbye Przykładowy komunikat narzędzia ldd dla programu goodbye: linux vdso.so.1 (0x00007ffc8f2bb000) libmessage.so => not found libc.so.6 => /lib/x86_64 linux gnu/libc.so.6 (0x00007fb6d41c1000) /lib64/ld linux x86 64.so.2 (0x00007fb6d458e000) Przy próbie uruchomienia programu pojawi się błąd:./goodbye./goodbye: error while loading shared libraries: libmessage.so: cannot open shared object file: No such file or directory
Biblioteki statyczne a współdzielone i Rozwiązanie: zmiana ustawień systemowych instalacja libmessage.so w katalogach standardowych ustawienie zmiennej środowiskowej LD_LIBRARY_PATH na dodatkową ścieżkę bibliotek współdzielonych: $ export LD_LIBRARY_PATH=$(pwd) po tej operacji ldd zwróci: linux vdso.so.1 (0x00007ffd78552000) libmessage.so => /opt/cpp_examples/libmessage.so (0x00007fc909dd2000) libc.so.6 => /lib/x86_64 linux gnu/libc.so.6 (0x00007fc909a07000) /lib64/ld linux x86 64.so.2 (0x00007fc909fd5000)
GNU Binutils i GNU Binutils - zbiór narzędzi do tworzenia i obróbki plików wykonywalnych. Składa się z: asemblera (GNU Assembler) linkera (GNU Linker) biblioteki obsługi różnych formatów plików z kodem narzędzi do obróbki plików z kodem (np. objdump) Binutils jest używany jako back-end przez GCC, ale też wiele innych programów operujących na kodzie.
GNU Assembler i Przetwarza kod skompilowany do języka maszynowego w kod nadający się do wykonania przez konkretny procesor. GNU as obsługuje wiele różnych rodzin mikroprocesorów (włącznie z Intel IA32, czyli x86) GNU as w danym systemie Linux jest wstępnie skonfigurowany do pracy z procesorem, na którym pracuje ów system, jednak można tą konfigurację zmienić (cross-compilation!) Język maszynowy programu Hello World: gcc S hello.c Kompilacja źródła hello.s: as o hello.o hello.s
GNU Linker i Aby kod programu był wykonywalny, musi on zostać sformatowany do postaci ELF (Executable and Linkable Format), zrozumiałej przez systemy UNIX. Format ten obowiązuje: pliki wykonywalne, pliki obiektowe, bibliotki współdzielone zrzuty pamięci Za formatowanie do ELF odpowiedziany jest linker. Linker jest również odpowiedzialny za sprawdzenie, czy kod uruchamiany podczas startu (plik crtbegin.o automatycznie dołączany do aplikacji) oraz zamykania aplikacji (crtend.o) znajduje się w prawidłowym miejscu kodu wykonywalnego
GNU Linker i objcopy - kopiuje i przekształca pliki obiektowe generowane przez kompilator objdump - zapisuje zawartość wykonywalnych plików binarnych w formacie tekstowym; wizualizuje zawartość plików wykonywalnych. Przykład: $ objdump x d S hello
GNU Debugger i C.D.N.
Rodzaje toolchain-ów Pojecia podstawowe: build machine (platforma budująca) - platforma budująca toolchain host machine (platforma hosta) - platforma na której działa toolchain target machine (platforma docelowa) - platformam, na ktorej działa skompilowany program. Rodzaje toolchain-ów Native build machine host machine target machine arch. A arch. A arch. A i build machine host machine target machine arch. A arch. A arch. B
Rodzaje toolchain-ów i Cross-native - gdy toolchain działa na maszynie docelowej build machine host machine target machine arch. A arch. B arch. B Canadian - rzadko spotykany build machine host machine target machine arch. A arch. B arch. C
Kompilacja skrośna (cross-compilation) Narzędzia do kompilacji skrośnej muszą rozwiązywać dwa podstawowe problemy: wszystkie wykorzystywane przez budowany program biblioteki C/C++ muszą być dostępne na maszynie budującej (build machine) kompilator oraz towarzyszące mu narzedzia musi generować kod możliwy do wykonania na platformie docelowej (target machine) Główne elementy kompilacji skrośnej: toolchain do kompilacji skrośnej biblioteki C system plików (root filesystem, sysroot) na maszynie hosta z bibliotekami i plikami nagłówkowymi obecnymi również na platformie docelowej cross-compilation toolchain + sysroot = SDK i
Narzędzia - Buildroot Buildroot zbiór skryptów Makefile oraz patch-ów do budowy obrazów Linux dla systemów wbudowanych. Generuje: toolchain do kompilacji skrośnej system plików (root filesystem) obraz jądra (kernel image) obraz programu rozruchowego (bootloader image) Obsługuje różne architektury procesorów: x86, ARM, MIPS, PowerPC, etc. Autor: Peter Korsgaard Objęty licencją GNU GENERAL PUBLIC LICENSE V2 Wykorzystanie Buildroot do budowy obrazu systemu dla Raspberry Pi: http://www.xappsoftware.com/wordpress/2013/06/06/how-tocreate-a-buildroot-environment-for-raspberry-pi/ i
Narzędzia - Crosstool-NG i Crosstool-NG Bardziej elastyczny (skalowalny) od Buildroot Strona: http://crosstool-ng.org Wykorzystanie Crosstool-NG do budowy kompilatora C i C++ dla Raspberry Pi: http://www.kitware.com/blog/home/post/426
Narzędzia - Eclipse i Eclipse Eclipse + konfiguracja + Toolchain dla Intel Galileo: https://software.intel.com/en-us/iot/downloads Wykorzystanie Eclipse do kompilacji skrośnej dla Raspberry Pi: http://hertaville.com/2012/09/28/development-environmentraspberry-pi-cross-compiler/