Mistä tässä harjoitteessa on kyse

Tämä harjoite perustuu demoissa 1 ja 2 esiteltyihin perustaitoihin, jotka oletetaan alustavasti tunnetuksi ja joita koko ajan harjoitellaan lisää. Erityisesti tulisi jo olla jollain tapaa miellyttävää toimia pääteyhteyden yli ja editoida lähdekoodia (=tekstitiedosto) yhdessä screen-ikkunassa ja käyttää komentoriviä toisessa. Komentojen ja argumenttien antaminen shellissä pitäisi olla tuttua samoin kuin ohjelmien tulosteiden tulkitseminen päätteeltä ja interaktiivisten tekstipohjaisten ohjelmien käyttely ym.

Huomioi seuraavaa:

• Käännökset ja kokeilut on tarkoitus tehdä pääteyhteydellä yliopiston etäkoneessa jalava.cc.jyu.fi tai halava.cc.jyu.fi tai itka203-testi.it.jyu.fi.
• Jomman kumman suorakäyttökoneille asennetun tehokkaan tekstieditorin (emacs tai vim) opettelu on suositeltavaa. Selviytymisohjeet suomeksi löytyvät demosta 2, mutta toki ohjelmien oman englanninkielisen tutoriaalin läpikäynti on aina paras vaihtoehto. Netistä löytyy myös paljon hyviä videotutoriaaleja molempiin editoreihin!
• Tekstieditoinnin voi tehdä hätätilanteessa helppokäyttöisellä nano -editorilla... Syntaksin mukainen väritys auttaa elämässä sen verran, että myös karvahattu-Nano kannattaa laittaa värittämään sen minkä se pystyy. Kopioi siis demossa linkitetty nanorc_patka -niminen tiedosto kotihakemistoosi tiedoston ~/.nanorc jatkeeksi, jos se ei vielä tue C-kielen väritystä. Pyydä tähän apuja lähiohjauksessa, jos tuntuu vaikealta. (Viimeisenä, ei missään nimessä suositeltavana, keinona voi editoida tiedostoja mikroluokassa Windowsin Notepad++ -editorilla tai vastaavalla järkevällä editorilla; tämä toimintamalli on kuitenkin historiallisesti korreloinut arvosanatavoitteen 1 tai "hylätty" kanssa, joten edelleen suosittelen laajentamaan omaa teknistä repertuaaria, jos se vain on henkisesti mahdollista itsellesi).
• Ei tarvitse pelätä että tällä kurssilla tehtäisiin kovin suuria ohjelmointisuorituksia. Enemmänkin katsellaan ja yritetään ymmärtää. Demotilaisuuksissa tai sähköpostitse tarjotaan apua, jos ei muuten aukene. Mikäli ohjelmointi tuntuu hankalalta ymmärtää, on syytä kerrata kurssin Ohjelmointi 1 asioita.

Harjoituksen tavoitteet:

• Teet omin käsin luennoilla nähtyjä käytännön toimenpiteitä, jolloin niiden merkitys toivon mukaan konkretisoituu. Erityisesti käännät ja suoritat C-kielisen ohjelman.
• Näet alustavasti, millaisia asioita POSIX-standardi määrittelee löytyväksi "matalan tason" kirjastoissa yhteensopivassa järjestelmässä.
• Perinteisistä ohjelmien toiminnan mukauttamiseen vaikuttavista keinoista käydään tarkoin läpi komentoriviargumentit ja ympäristömuuttujat.
• Lasket yksinkertaisia laskutoimituksia eri lukujärjestelmillä ja teet muunnoksia lukujärjestelmästä toiseen. Yleisön pyynnöstä on mukana vapaaehtoinen lisäharjoitus jotta on mahdollista harjaannuttaa tätä taitoa. Erityisesti kaksi- ja heksadesimaalijärjestelmä ovat käyttöjärjestelmien (ja lisäksi mm. tietoliikennetekniikan) parissa paljon käytettyjä lukujärjestelmiä kymmenjärjestelmän tilalla.

Keväällä 2015 määriteltyjen osaamistavoitteiden osalta demon tehtyään opiskelija:

• ymmärtää komentoriviargumenttien ja ympäristömuuttujien roolin sovellusohjelman toimintaympäristön osana; osaa antaa käyttöohjeiden mukaisia argumentteja komentoriviohjelmille sekä julkaista ympäristömuuttujia bash-kuoressa [ydin/arvos2]
• osaa tarkastella minkä tahansa muotoisen tiedoston sisältöä heksavedoksena (hex dump) ja suoritettavan ohjelmatiedoston sisältöä tekstimuotoisen debuggerin disassemblerilla; osaa tehdä arvion todennäköisestä tiedostoformaatista heksavedoksen perusteella [ydin/arvos2]

Alustavalla tasolla C-koodin (ei vielä bashin) osalta opiskelija:

• osaa ohjeita tai esimerkkiä mukaillen hyödyntää ohjelmalle annettuja komentoriviargumentteja ja ympäristömuuttujia omassa C-ohjelmassa sekä omassa bash-skriptissä jonkin toiminnallisen tavoitteen saavuttamiseksi [edist/arvos3]

Lisäksi tähdätään edelleen useaan muuhun osaamistavoitteeseen, jotka viedään perille myöhemmissä demoissa.

Ohjeita

Aiemmissa demoissa teit oman kotihakemistosi alle hakemistot Käyttöjärjestelmät-kurssin ensimmäisille harjoitteille. Ota jälleen pääteyhteys IT-palveluiden suorakäyttökoneeseen ja aseta työhakemistoksesi tämän kolmannen demon hakemisto, nimeltään esim. ~/kj17/demo3/ tai muuta vastaavaa. (Muistele tarvittaessa aiempia demoja: miten hakemisto vaihdettiin, miten varmistettiin, mikä on nykyinen työhakemisto, jne. ...)

Kun olet demo 3:n hakemistossa, hae esimerkkikoodi kurssin materiaalitietovarastosta, eli komenna shellissä:

wget https://yousource.it.jyu.fi/itka203-kurssimateriaalikehitys/itka203-kurssimateriaali-avoin/blobs/raw/master/2015/esimerkit/l04_helloworld.c

Huom 1: Pitkä ja hankala URL varmaan kannattaa varovaisesti leikata ja liimata pääteyhteysohjelmaan.. Varmista, että olet varmasti kopioinut komennon tai URLin web-selaimesta leikepöydälle. Kun olet varma, että leikepöydällä on täsmälleen ylläoleva komento, uskallat liittää sen pääteyhteysikkunaan shelliin, joka odottaa komentoa. KiTTYssä ja PUTTYssä klikataan hiiren oikeanpuoleista nappia; Linux-käyttäjät klikkaavat keskimmäistä nappia ja Mac-käyttäjät tekevät mahdollisesti jotain muuta. Tavoitteena on tavalla tai toisella suorittaa yllämainittu komento, joka hakee Internet-yhteyden yli WWW:stä yhden tiedoston.

Huom 2: Free software foundationin ohjelma wget ei ole määritelty POSIX-standardissa, mutta se on niin näppärä, että käytämme sitä nyt. POSIX kyllä määrittelee samaan tarkoitukseen ohjelman curl, johon mahdollisesti palataan, kun shell ja skriptiohjelmointi saadaan hieman tukevammalle pohjalle.

Hae vielä seuraava:

wget https://yousource.it.jyu.fi/itka203-kurssimateriaalikehitys/itka203-kurssimateriaali-avoin/blobs/raw/master/2015/demot/mallikoodia/d03_fiilikset.c

Ja mikäli suosituksista huolimatta käytät tekstin editointiin nanoa, etkä vimiä tai emacsia, niin tee ihmeessä myös seuraavat operaatiot, jotta C-koodi näyttää mielekkäämmältä editorissa:

wget https://yousource.it.jyu.fi/itka203-kurssimateriaalikehitys/itka203-kurssimateriaali-avoin/blobs/raw/master/2015/demot/mallikoodia/nanorc_patka

cat nanorc_patka >> ~/.nanorc

Huom 3: Etäpalautuksen vuoksi emme täydellisesti pysty toteamaan, että olet tehnyt noin viisitoista minuuttia kestävän palautustehtävän lisäksi kaikki tehtävät aivan itse ja oppinut niistä -- jokainen on oman onnensa nojassa, ja "teknisesti sallittu" laiskuus on jokaisen oma häpeä. Tentti sen sitten kertoo, mitä itse kukin on oppinut. Näillä sanoin työn touhuun... Kaikki tämän demon vaiheet kuuluvat kurssin sisältöön.

Ensimmäinen C-ohjelma

Katso tekstieditorilla ohjelmaa l04_helloworld.c -- siitä nähdään yksinkertaisen C-ohjelman muoto. Tällainenhan se on (rivinumerot lisätty tulosteeseen):

1  #include <stdio.h>
2  int main(int argc, char **argv){
3      printf("Hello World!\n");
4      return 0;
5  }

Selitetään merkitys rivi riviltä, ja peilataan olio-ohjelmoinnista (esim. C# tai Java) tuttuihin asioihin. Syntaksiin mennään tarkemmin myöhemmin; nyt mietitään vain rivien merkitystä ohjelman kannalta.

Rivi 1:

#include <stdio.h>

Tällä liitetään mukaan tiedosto stdio.h. Tällaiset .h -päätteiset tiedostot ovat ns. otsikkotiedostoja (Header file), joiden perusteella C-kielen kääntäjä tietää, millaisen rajapinnan jokin kirjasto (tai kirjaston osa) tarjoaa. Nimenomainen stdio (Standard input/output) tarkoittaa perusmallin syöttö- ja tulostusvälineistöä, jollainen aina löytyy ja jota vastaava kirjastokin liitetään ohjelmaan ilman erillistä pyyntöä. Tässä ohjelmassa tulostetaan printf() -aliohjelmalla, jonka otsikko on nimenomaan tiedostossa stdio.h. Lähin vastine esimerkiksi Javassa on import -avainsana, jolla lähdekooditiedoston alussa ilmoitetaan, minkä nimenomaisen kirjaston rajapintaa halutaan käyttää - esimerkiksi fi.jyu.mit.kurssit.munkurssi.Harpake voi olla aivan erilainen kuin joku.muu.organisaatio.kirjasto.Harpake. Tiedoston alussa voisin haluta kirjoittaa siis import fi.jyu.mit.kurssit.munkurssi, minkä jälkeen Harpake on se luokka, jota oikeasti tarkoitan. Samoin kuin oliokielisten lähdekoodien alussa on paljon import -rivejä, C-ohjelmien alussa on usein paljon #include -rivejä.

Otsikkotiedosto sisältää vain tiedon rajapinnan määrittelystä (eli kunkin aliohjelman nimen sekä sen parametrien ja paluuarvon tyypit); itse kirjastot on liitettävä vielä erikseen joko lähdekoodina (käännöksen yhteydessä) tai käännettyinä eli ns. binäärisinä kirjastoina (linkitysjärjestelmän avulla, mikä on tyypillinen ja joustavampi tapa). Kirjastot, linkittäminen ja ohjelman lataaminen käydään tarkoin läpi kevään 2015 luennoilla.

Konkretiaa halajaville todettakoon, että otsikkotiedosto stdio.h on suorakäyttökoneellamme sijainnissa /usr/include/stdio.h, mistä se löytyy automaattisesti, koska koneelle asennettu kääntäjä osaa oletusarvoisesti etsiä otsikoita mm. hakemistosta /usr/include. Otsikkotiedostossa luvatulla rajapinnalla varustetun aliohjelman printf() konekielinen koodi puolestaan on osa kirjastoa, joka löytyy suorakäyttökoneellamme sijainnissa /lib64/libc.so.6. Ohjelman käynnistysvaiheessa käyttöjärjestelmän ns. lataus- ja linkityskoodi osaa ladata ja liittää suoritettavan prosessin koodiin juuri tuon kirjaston, koska ELF-muotoiseen ohjelmatiedostoon on tallennettu tieto kaikista tarvittavista kirjastoista. Tämä libc sisältää kaikkein yleisimmät ja useimmin C-kielessä tarvitut, standardin määrittelemät kirjastoaliohjelmat, joten se liitetään ohjelmiin automaattisesti ilman erillistä pyyntöä. (Mikään pakko ei ole käyttää libc:tä, jos vaikkapa hullutellakseen tai muusta syystä pitää karsia ohjelmatiedoston koko absoluuttiseen minimiin - silloin pitää kuitenkin käännösvaiheessa suorastaan kieltää kääntäjää hyödyntämästä standardikirjastoa). Muut kirjastot täytyy erikseen ilmoittaa, kun suoritettava ohjelma luodaan kääntäjällä ja muilla apuohjelmilla. Mitään mystiikkaa näihinkään asioihin ei liity, mikä on hyvä tiedostaa heti aluksi. Aiheesta jatketaan seuraavassa demossa, jossa käännetään erikseen oma minikirjasto ja liitetään se vaiheittain osaksi kokonaista ohjelmaa.

Rivi 2:

int main(int argc, char **argv){

Tästä alkaa C-ohjelman suoritus. On sovittu C-kielen määrittelyssä sekä sitä kautta myös mm. POSIX-standardissa, että ohjelman suoritus tarkoittaa (kyseisessä laitteistossa ja käyttöjärjestelmässä tarvittavien, automaattisesti tapahtuvien alustusoperaatioiden jälkeen) sellaisen aliohjelman kutsumista, jossa:

• nimi on main
• paluuarvo on int eli kokonaisluku
• on kaksi parametria, joista ensimmäinen on int-tyyppinen ja toinen on char * * -tyyppinen eli osoitin merkkijonotaulukkoon (älä vielä huoli tietotyypeistä, niihin syvennytään seuraavassa demossa).

Tämä on ihan samanlainen sopimusasia kuin se, että C#-luokan suoritus tarkoittaa seuraavanlaisen luokkametodin kutsumista:

public static void Main(string[] args)

Tai että Java-luokan suoritus tarkoittaa seuraavanlaisen luokkametodin kutsumista:

public static void main(String[] args)

Huomataan, että C, kuten C# tai Javakin, on lohkorakenteinen, ja lohkojen syntaksikin on sama: lohko alkaa kiharasululla { ja päättyy vastaavaan käänteiseen sulkuun }. Muutenkin syntaksissa on yhtäläisyyttä: C:n aliohjelmat aloitetaan muodossa:

PALUUARVON_TYYPPI aliohjelmanNimi(TYYPITETTY_PARAMETRILISTA)

joka on täysin sama kuin C#:n tai Javan metodimäärittelyn syntaksi (varmasti ainakin sen takia, että nämä myöhemmät kielet on tarkoituksella tehty samannäköiseksi kuin C). Myös C:ssä aliohjelmamäärityksen eteen laitetaan tarvittaessa lisämääreitä (kaikki määreet eivät kuitenkaan tarkoita samaa uudemmissa kielissä! Esim. static on C-kielessä ihan eri asia kuin C#:ssa tai Javassa).

Rivi 3:

printf("Hello World!\n");

Tällainen on C:ssä aliohjelmakutsun syntaksi. Eikö näytäkin samalta kuin C#:ssa tai Javassa metodin käyttäminen? Paitsi että usein oliokielissä kutsutaan pistenotaatiota käyttämällä jonkun olion instanssimetodia; esimerkiksi C#-kutsussa System.Console.WriteLine("juu") ja vastaavassa Java-kutsussa System.out.println("juu") kutsutaan System -luokan luokka-attribuuttina löytyvän Console tai out-nimisen viitteen osoittamana löytyvän luokan instanssille metodia WriteLine tai println, ja metodille annetaan parametriksi viite vakiopoolissa sijaitsevaan string tai String -luokan instanssiin.

C:n tulostus on vähän lyhyempi selittää täsmällisesti kuin oliokielten luokkahässäkät: esimerkin rivi 3 siirtää prosessorin suorituksen aliohjelman printf ensimmäiseen käskyyn, sen jälkeen kun parametriksi on laitettu merkkijonon Hello world!\n ensimmäisen merkin eli kyseisen H:n osoite muistissa.

Huomaa, että C:n lauseet tulee päättää puolipisteellä ; ihan niinkuin C#:ssa tai Javassakin. Ylipäätään syntaktiset erot ovat erittäin pieniä. Varsinaiset erot kielissä johtuvat C:n yksinkertaisuudesta olioita tukeviin seuraajiinsa nähden.

Rivi 4:

return 0;

Ohjelmat voivat kertoa operaation onnistumisesta tai epäonnistumisesta virhekoodilla. Se on kokonaisluku, jonka ohjelman käynnistäjä saa haltuunsa. C-kielessä koodi annetaan main() -aliohjelman paluuarvona, eli tuon arvon asettaminen on viimeinen asia, minkä käyttäjän ohjelma suorittaa. Yleensä 0 tarkoittaa, että mitään virhettä ei tullut. Kokonaisluvun on tarkoitus olla positiivinen, ja esim. POSIX-standardin mukaan siitä huomioidaan vain 8 alinta bittiä. Näin ollen mahdollisia paluuarvoja on 256 kappaletta. POSIX määrää niistä osan tiettyihin tarkoituksiin. Katso tarvittaessa, mitä standardi sanoo aiheesta "exit code".

Rivi 5:

}

Kun aliohjelman sisällön määrittelevä lohko avataan ohjelman alussa, niin toki se pitää lopuksi sulkea. Ihan samoin kuin C#:ssa, Javassa ja muissakin lohkorakenteisissa kielissä, joiden syntaksi on tarkoituksella johdettu C:stä.

Käännä ja testaa ohjelmaa suorakäyttökoneessa shell-yhteydellä. Komenna:

c99 l04_helloworld.c

Jos kaikki meni hyvin, ohjelma kääntyi oletusnimelle a.out, jonka voit nyt suorittaa komennolla:

./a.out

Toivottavasti tulostui se, mitä odotitkin. Huomaa, että shell ei etsi ajettavia tiedostoja automaattisesti nykyisestä työhakemistosta. Ajaaksesi jotakin työhakemistosta, pitää kertoa eksplisiittisesti, että haluat ajaa ohjelman tästä hakemistosta eli ./ eli piste ja kauttaviiva.

Ohjelman ilmeneminen laitteistossa: lähdekoodi, binääritiedosto

Toista itse luennoilla näytetyt esimerkit, joilla tutustuttiin tiedon esitystapoihin tietokoneessa.

Näytä olennaiset tiedot työhakemiston tiedostoista, mukaanlukien lähdekooditiedosto:

ls -l

Näytä enemmän metatietoja liittyen yhteen tiedostoon:

stat l04_helloworld.c

Näytä tiedoston sisältö (mikä on eri asia kuin sen sijainti tai muut metatiedot) tavu tavulta niin kuin se on:

hexdump -C l04_helloworld.c

Näytä kääntäjän tuottaman suoritettavan ohjelmatiedoston sisältö, sivuttajaohjelmaa hyödyntäen:

hexdump -C a.out | less

Noin viidennen luennon paikkeilla käytäneen läpi, mitä osioita suoritettavan ohjelmakoodin sisällä on, ja mitä toimenpiteitä käyttöjärjestelmän tarvitsee tehdä, että tällainen bittipötkö saadaan ladattua tietokoneen muistiin ja käynnistettyä prosessiksi.

Ensimmäinen katsaus komentorividebuggeriin (gdb)

Otetaan tässä demossa ensikosketus debuggeriin, jotta se tulee tutuksi mahdollisimman varhaisessa vaiheessa. Käännä ohjelma seuraavalla komentorivillä:

c99 -g -O0 l04_helloworld.c

Nyt argumentti -g ilmoittaa kääntäjälle, että käännettyyn ohjelmaan pitää laittaa mukaan virheenkorjausta eli debuggausta helpottavia asioita, kuten tieto alkuperäisen lähdekoodin tiedostonimistä ja rivinumeroista. Argumentti -O0 eli viiva, iso O-kirjain ja nolla puolestaan kieltää kääntäjää tekemästä automaattista optimointia konekielikoodiin. Tällä kurssilla käytetään mielellään kaikissa esimerkeissä optiota -O0, jotta syntyvä konekieli vastaa mahdollisimman läheisesti alkuperäistä C-ohjelmaa. Oikeiden tuotantokoodien julkaisussa puolestaan käytettäisiin esimerkiksi optiota -O3 jolloin ohjelman konekielinen koodi toimisi paljon nopeammin. Nopeutus perustuisi kuitenkin mm. konekielikäskyjen suoritusjärjestyksen muuttamiseen, konekielikäskyjen käyttämiseen eri tarkoituksiin kuin ne manuaalin mukaan on suunniteltu, muuttujien pitämiseen rekistereissä muistin sijasta ja ylimääräisen koodin generointiin ynnä muuhun automaattisesti tehtävään kikkailuun. Kääntäjän automaattisesti optimoima koodi voi olla hyvin kinkkisen näköistä suhteessa alkuperäiseen lähdekoodiin, millä emme halua vaivata päätä, kun tarkoitus on ymmärtää perusteita. Optimoimattomassa koodissa jokaista C-kielistä koodiriviä kohden generoituu korkeintaan muutamia selkeästi ymmärrettävissä olevia konekielisiä käskyjä, jotka ovat mukavan selkeästi peräkkäin.

Nyt pitäisi olla syntynyt taas suoritettava a.out, jonka koko on hieman aiempaa isompi, johtuen mukana olevasta debuggaustiedosta. Normaali suorittaminen näyttänee samalta kuin aiemmin. Nyt ajetaan ohjelmaa kuitenkin debuggerissa. Komenna shellissä:

gdb a.out

Mitäs nyt? Tilanne näyttää seuraavalta ja vaatii hieman selitystä:

[nieminen@halava esimerkit]$ gdb a.out
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
...
(gdb)   [ja vilkkuva kursori ...]

Käynnistit debuggerin. Ohjelmointi 1:ltä pitäisi olla jossain määrin tuttu asia jokin (esim. Visual Studion tai Eclipse IDE:n) graafinen debuggeri, jolla voi opiskella ohjelman toimintaa, ja jota voi käyttää virheenetsinnässä (siitä niiden nimi "de-" "bugger"). Nyt käytettävä gdb on samanlainen, mutta komentorivikäyttöinen. Tällekin on olemassa graafisia julkisivuja eli front-endejä, mutta interaktiivisten komentoriviohjelmien käyttö on yksi tämän kurssin teemoja, joten noudatamme sitä loppuun asti.

Debuggeri odottaa nyt siis tekstimuotoisia komentoja, joiden avulla voit tutkia argumenttina annetun ohjelman toimintaa. Komenna debuggeria:

run

Debuggeri käynnisti käännetyn ohjelman, antoi sen mennä niin pitkälle kuin se ilman virheitä etenee, tässä tapauksessa onnistuneeseen loppuun saakka. Tulostui toivon mukaan seuraavankaltaista:

Starting program: /autohome/nashome3/nieminen/charragit/itka203-kurssimateriaali-avoin/2015/esimerkit/a.out
Hello world!

Program exited normally.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.x86_64

Viimeinen rivi tarkoittaa, että suorakäyttökoneillamme ei ole asennettuna debug-tietoja standardikirjastoille. Ei välitetä siitä. Itse käännettyjen ohjelmien debuggaukseen tämä ei vaikuta, koska debug-tiedot laitetaan mukaan käännösvaiheessa. Ohjelman ongelmattomasta loppumisesta saatiin tässä ilmoitus. Jos ohjelma olisi kaatunut, debuggerin avulla voisi alkaa selvittelemään, miksi niin kävi...

Tekstipohjainen ohjelma on erilainen kuin graafinen ohjelma, mutta se voi olla käyttäjäystävällinen omalla tavallaan. Esim. gdb:n käyttäjäystävällisyys toteutuu mm. seuraavin tavoin:

• Komennoista saa ohjeita komentamalla help. Eli komentoja ei tarvitse muistaa, vaan ne saa esille aina ohjelman käytön yhteydessä ilman tarvetta tarkistaa ulkopuolisesta manuaalista tai netistä.
• Komennoissa on automaattitäydennys tabulaattorinäppäimellä, ja niille on lyhyitä "alias"-nimiä, jotka on nopea kirjoittaa (ks. helpit).
• Komentohistoria on käytettävissä samoilla tehokäyttönäppäimillä kuin bash-shellissä.
• Edellisen komennon voi toistaa painamalla pelkkää enteriä. Debuggerissa on tyypillistä mm. askeltaa ohjelmaa yksi rivi tai käsky kerrallaan useiden silmukkakierrosten ym. pitkien "jälkien" läpi, joten tämä on tehty yhtä helpoksi kuin enterin painelu peräkkäin.

Debuggerin käyttöliittymä on paljolti samanlainen kuin tehokkaan interaktiivisen shellin -- tai minkä tahansa hyvin tehdyn tekstipohjaisen ohjelman. Mm. suositun laskentaohjelmisto Matlabin "Command Window" on samalla tavoin kätevä. Tässä vaiheessa lienee käynyt selväksi, että tekstikomennoilla toimiva käyttöliittymä tukee luonnostaan myös komentojen täsmällistä tallentamista, toistamista ja skriptiksi asettelemista.

Käväistään vähän aikaa pois debuggerista; siitä pääsee pois komennolla:

quit

Olet nyt käyttänyt komentorividebuggeria kerran ja lopettanut sen nätisti. Seuraavaksi tutustutaan debuggeriin askelta tarkemmin. Eli askelletaan ohjelman läpi rivi riviltä.

Eli uudelleen vaan käyntiin:

gdb a.out

Debuggeri on jälleen ladannut pyydetyn ohjelmatiedoston, ja se on valmis avaamaan konepellin oikein kunnolla. Katsotaan ensin yleiskuvaa ohjelmasta debuggerin disassembly-ominaisuudella. Komenna seuraavasti:

disassemble /mr main

Debuggerin ohjauskomento on tässä disassemble eli "pura konekieli symboliseen, ihmisen ymmärtämään, muotoon". Oletusarvoisesti komento näyttäisi vain käskyjen muistiosoitteet ja symbolit, mutta täydellisyyden vuoksi käytetään nyt lisukkeita /m ja /r joilla mukaan liitetään debug-tiedoista saatu alkuperäinen lähdekoodi sekä todellinen muistissa sijaitseva konekielinen tavujono.

Koska ohjelmaa ei vielä ole käynnistetty, pitää gdb:lle kertoa eksplisiittisesti, mistä aliohjelmasta disassembly halutaan tehdä (toki näin voi aina tehdä muutenkin; oletuksena disassembly näytetään siitä aliohjelmasta, jonka sisällä suorituskohta milloinkin on).

Pitäisi näkyä pääohjelman assembler-koodi alkaen jotenkin seuraavasti:

Dump of assembler code for function main:
2       int main(int argc, char **argv){
   0x00000000004004c4 <+0>:      55     push   %rbp
   0x00000000004004c5 <+1>:      48 89 e5       mov    %rsp,%rbp
   0x00000000004004c8 <+4>:      48 83 ec 10    sub    $0x10,%rsp
   0x00000000004004cc <+8>:      89 7d fc       mov    %edi,-0x4(%rbp)
   0x00000000004004cf <+11>:     48 89 75 f0    mov    %rsi,-0x10(%rbp)

3         printf("Hello world!\n");
   0x00000000004004d3 <+15>:     bf e8 05 40 00 mov    $0x4005e8,%edi
   0x00000000004004d8 <+20>:     e8 db fe ff ff callq  0x4003b8 <puts@plt>

4         return 0;
   0x00000000004004dd <+25>:     b8 00 00 00 00 mov    $0x0,%eax

5       }
   0x00000000004004e2 <+30>:     c9     leaveq
   0x00000000004004e3 <+31>:     c3     retq

End of assembler dump.

Nyt, kun ohjelma on käännetty debug-tietojen kanssa, osaa gdb liittää assembler-tulosteeseen C-koodirivit (rivinumero ja kyseisellä rivillä oleva koodi). Tämä on havainnollista, koska nähdään suoraan, mikä koodin osa kääntyy minkäkinlaiseksi konekieleksi. Huom: tämä demo on vasta työkaluun tutustumista ja ennakoiva katsaus.. tässä nähtävien käskyjen ja rekisterien roolista puhutaan kaikessa rauhassa luentojen 6 ja 7 paikkeilla ja mahdollisesti myöhemminkin, ja niistä jatketaan pienin askelin myöhemmissä demoissa. Tässä vaiheessa riittää oppia ja kokeilla itse, miten saat käännetyn ohjelman konekielen debuggerilla avattua konkreettisesti silmiesi eteen, ja tietää alustavasti minkä tyyppisiä asioita debuggeri silloin näyttää.

Selitys asioille, jotka debuggeri näyttää:

• Vasemmassa reunassa on 64-bittinen heksaluku. Tämä on muistiosoite, josta käskyn konekielinen bittijono alkaa.
• Seuraavaksi on suhteellinen osoite aliohjelman alusta lähtien. Siis esim. <main+4> tarkoittaa että kyseinen käsky alkaa muistipaikasta, joka saadaan lisäämällä main() -aliohjelman ensimmäisen käskyn osoitteeseen 4. Huomataan, että x86-64:ssä konekielikäskyjen bittijonot voivat olla eri mittaisia (riippuen siitä, onko mukana vakioarvoja, ja siitä ovatko käskyt alkuperäisiä 8086-käskyjä vai myöhempiä laajennoksia).
• Seuraavaksi on konkreettinen käsky tavujonona siten kuin se on tietokoneen muistissa tallessa, peräkkäisissä osoitteissa.
• Sitten on käsky ns. AT&T-syntaksilla eli mnemonic ja operandit. Luentomonisteen konekielitä esittelevä luku kertoo näistä esimerkkejä; totuus rajapintasopimuksista on prosessorivalmistajan julkaisemassa manuaalissa. Yksi assembly-kielinen rivi ja sen konekielinen tavujono vastaavat käytännössä toisiaan lähes yksi-yhteen.

Huom: Suurin osa ohjelmien tarvitsemista rakenteista hoituu muutamilla peruskäskyillä, joista kaikkein yleisimpiä kiteytetään luentomonisteessa tämän johdantokurssin esimerkeiksi. Nykyiset prosessorimanuaalit ovat kuitenkin laajuudeltaan useampituhatsivuisia, johtuen niiden monipuolisuudesta: Joitakin satoja sivuja on käskyjen toiminnan kuvailua. Valtaosa nykyprosessorin käskyistä liittyy erityistehtäviin kuten liukulukulaskentaan. Myös prosessoriytimien keskinäinen synkronointi edellyttää runsaasti sivuja nykyprosessorien manuaaleissa. Erityisesti x86-64:n manuaaleja pidentää myös se, että ne joutuvat kuvailemaan myös kaikkien aiempien x86-sarjan prosessorien toiminnan, koska yhteensopivuus aiemman binäärikoodin kanssa on säilytetty. Manuaalien alkupuolella on hyödyllistä ja selkeästi kirjoitettua johdantomaista selitystä laitteiston toiminnasta. (Vinkki iltalukemiseksi, mikäli kiinnostut aiheesta enemmän.)

Nyt kun ymmärrät näkemäsi, askella vielä omin käsin läpi "Hei maailma"-ohjelma C-koodirivi kerrallaan, samoin kuin luennolla näytettiin. Seuraavassa vielä uudelleen muistin virkistämiseksi:

Näin debugger antaa automaattisten alkutoimenpiteiden tapahtua ja pysäyttää suorituksen main-aliohjelman ensimmäisen koodirivin kohdalle:

start

Katso ja tulkitse näkymää itse. Heitä uudelleen (komentohistoriasta tietysti, nuolinäppäimellä!) edellinen komento:

disassemble /mr main

Katso ja tulkitse näkymää itse. Sehän on tietysti muuten sama kuin aiemmin, mutta nyt gdb näyttää vasemmassa laidassa symbolit => sen rivin alussa, jossa on seuraavaksi suoritettava konekielinen käsky. Ei vielä väliä, mitä käskyt tekevät. Totea nyt vaan, mitä tapahtuu, kun askellat yhden koodirivin eteenpäin:

step

Kaikki riviin liittyvät konekielikäskyt on nyt tehty ja debugger on pysäyttänyt suorituksen ennen seuraavaa lähdekoodiriviä. Totea tämä itse disassemblystä:

disassemble /mr main

Steppaile sitten vielä, ja totea tilanne:

step

step

Viimeisen stepin jälkeen aliohjelman main() suoritus päättyy. Voit itse todeta saman, mikä luennollakin nähtiin: päädytään alustakirjaston puolelle, josta järjestelmäämme ei nyt ole asennettu lähdekoodia tai debuggaustietoa, joten debuggeri ei voi paljoa enempää näyttää, vaan se antaa automaattisesti liitetyn alustus- ja lopetuskoodin hoitaa ohjelman lopputoimet. Sovellusohjelman ulkopuolista alustus- ja lopetuskoodia tarvitaan hoitamaan mukavuus- ja välttämättömyysseikkoja, jotka liittyvät tiettyyn käyttöjärjestelmätoteutukseen. Esimerkiksi C-kielen määrittelyssä ohjelman virhekoodiksi tulkitaan main-aliohjelman paluuarvo, mutta käyttöjärjestelmätoteutus odottaa saavansa sen käyttöjärjestelmän kutsurajapinnan kautta, johon alustariippumaton C-koodi ei edes pääse itse käsiksi. Normaalisti tarvitaan siis vielä jotakin pikkukoodia, joka tekee järjestelmäsidonnaiset alkutoimet, kutsuu mainia, ja suorittaa lopputoimet. Luennoilla (noin 5. tai 6. luento) nähdään myös, miten nämä pikkukoodit voitaisiin ohittaa, mutta jouduttaisiin tekemään rumia ja epästandardeja temppuja. Siis "mitä tapahtuu luennolla puhtaan assemblerin osalta, jääköön luennolle" (tekemisen tasolla, mutta niiden asioiden olemassaolo täytyy ymmärtää, ettei ohjelman käynnistyksen, suorituksen ja käyttöjärjestelmäkutsun roolin suhteen jää epäselvyyksiä).

Komentoriviargumentit, ympäristömuuttujat

Ohjelman toimintaan voi perinteisesti vaikuttaa mahdollisen graafisen tai tekstimuotoisen käyttöliittymän ja syötetiedostojen ym. reaaliaikaisten keinojen lisäksi kahdella vakiintuneella (ja mm. POSIXin edellyttämällä) tavalla: komentoriviargumenteilla ja ympäristömuuttujilla.

public class Argumentit{
    public static void main(String[] args){
        int i;
        System.out.printf("Ohjelman saamat komentoriviargumentit ovat:\n");
        for(i=0; i<args.length; i++){
            System.out.printf("Argumentti %d: %s\n", i, args[i]);
        }
    }
}

#include <stdio.h>
int main(int argc, char **argv){
    int i;
    printf("Ohjelman saamat komentoriviargumentit ovat:\n");
    for (i=0; i<argc; i++){
        printf("Argumentti %d: %s\n", i, argv[i]);
    }
}

javac Argumentit.java

c99 argumentit.c

java Argumentit kissa koira

./a.out kissa koira

export LC_ALL="en_US.utf8"

Pakollinen palautustehtävä

Pakollisessa palautustehtävässä verifioidaan, että olet onnistuneesti kääntänyt ja käynnistänyt C-kielisen ohjelman, antanut sille yhden argumentin, joka sisältää välilyönnin, ja asettanut ympäristömuuttujan avulla kieliasetukset ainakin siinä shell-sessiossa, jossa ajat kääntämäsi ohjelman. Vapaaehtoisena lisäosiona katsastetaan, että olet osannut laskea ja muuntaa lukuja eri lukujärjestelmissä.

Pakollisen C-ohjelman osuuden vastaus tuotetaan kääntämällä ja ajamalla alussa mainitusta URLista haettu C-lähdekoodi nimeltään d03_fiilikset.c siten, että tuloste ohjautuu shellissä vastaustiedostoon unix-rivinvaihtoineen aiemmissa demoissa opitulla syntaksilla, jossa käytetään väkästä >. Ei mitään copy-paste -kikkailuja tai "tarpeettomia echo-komentoja" edellenkään. Tulosteen pitäisi näyttää seuraavan malliselta (paitsi käyttäjätunnus on tietenkin omasi eikä nieminen, tuloste vastaa omia tunnelmiasi kurssilla jne..):

Ympäristömuuttuja USER   == nieminen
Ympäristömuuttuja HOME   == /nashome3/nieminen
Ympäristömuuttuja PWD    == /nashome3/nieminen/kj15_esimerkkidemot/demo3
Ympäristömuuttuja LANG   == en_US.utf8
Ympäristömuuttuja LC_ALL == en_US.utf8
argv[0] == ./a.out
argv[1] == Ihan kivalta tuntuu: uskokaa tai älkää, niin aikataulu pitää aiempaa paremmin.
Kertauksena: käyttäjän 'nieminen' tunnelmat tässä vaiheessa kurssia:

Ihan kivalta tuntuu: uskokaa tai älkää, niin aikataulu pitää aiempaa paremmin.

Kieliasetusten täytyy olla ohjelmaa ajettaessa joko britti- tai jenkkienglanti UTF8-merkistökoodauksella.

Keväällä 2017 kurssin demot ja niiden palautus hoidetaan Optimassa. Kullekin demolle on oma palautuslaatikko, johon tehtävässä tuotettu tiedosto palautetaan.

Tästä demosta palautetaan tasan yksi tiedosto nimeltään "d3_vastaus.txt", joka on luotu ohjaamalla C-ohjelman tuloste kyseiseen tiedostoon.