LXF133:ARM

Материал из Linuxformat.

Linux и ARM

ARM: Пи­шем про­грам­мы

Ста­тья из пре­ды­ду­ще­го но­ме­ра лишь раз­драз­ни­ла ваш ап­пе­тит? При­го­товь­тесь к на­стоя­ще­му де­лу: се­го­дня Ан­д­рей Бо­ров­ский бу­дет соз­да­вать ARM-при­ло­же­ния на обыч­ном ком­пь­ю­те­ре.

Раз­ра­бот­ка для мо­биль­ных уст­ройств пер­спек­тивнее, чем для ПК, и вот по­че­му. Важ­ную роль в раз­ви­тии ПО для на­столь­ных ком­пь­ю­те­ров сыг­рал рост про­из­во­ди­тель­но­сти их про­цес­со­ров, и хо­тя за­кон Му­ра по-прежнему спра­вед­лив, на­ра­щи­вание чис­ла ядер не при­во­дит к та­ко­му же росту про­из­во­ди­тель­но­сти, как уве­ли­чение так­то­вой часто­ты. ПК на­хо­дят­ся в ста­дии экстен­сив­но­го роста, тогда как мо­биль­ные уст­рой­ства еще не про­шли фа­зу ин­тен­сив­но­го, при ко­то­ром подъ­ем так­то­вой часто­ты, объ­е­мов опе­ра­тив­ной па­мя­ти, раз­ре­шаю­щей спо­соб­но­сти эк­ра­на не про­сто уско­ря­ет ра­бо­ту, но и от­кры­ва­ет пе­ред раз­ра­бот­чи­ком но­вые воз­мож­но­сти. Кро­ме то­го, на­чин­ка мо­биль­ных уст­ройств все еще не унифи­ци­ро­ва­на, и ор­ды про­грамм, напи­сан­ных для ста­рых гад­же­тов, не мо­гут быть ав­то­ма­ти­че­ски пе­ренесе­ны на но­вые. Все это соз­да­ет пре­крас­ную твор­ческую ат­мо­сфе­ру, в ко­то­рой та­лант­ли­вый про­грам­мист мо­жет все­сто­ронне про­явить се­бя.

Сред­ства раз­ра­бот­ки для мо­биль­ных уст­ройств столь же раз­но­об­раз­ны, как и са­ми уст­рой­ства – на­чи­ная с систем про­грам­ми­ро­вания на «го­лом же­ле­зе» и за­кан­чи­вая па­ке­та­ми раз­ра­бот­ки для спе­ци­фи­че­ских за­кры­тых сред. Мы же рас­смот­рим ин­ст­ру­мен­ты про­грам­ми­ро­вания для «пол­но­цен­ных Linux-систем» (не обя­за­тель­но мо­биль­ных), на ба­зе про­цес­со­ра ARM.

Scratchbox

По­про­сту го­во­ря, Scratchbox пред­став­ля­ет со­бой «пе­сочницу», в ко­то­рой мож­но вы­пол­нять раз­лич­ные дей­ствия (в том чис­ле в ре­жи­ме эму­ля­ции root), не за­тра­ги­вая ра­бо­ту осталь­ной систе­мы. Что от­ли­ча­ет Scratchbox от дру­гих «пе­сочниц», так это сре­да раз­ра­бот­чи­ка, на­стро­ен­ная на кросс-ком­пи­ля­цию. По­ми­мо x86, Scratchbox под­дер­жи­ва­ет ARM, а так­же, в экс­пе­ри­мен­таль­ном ре­жи­ме, PowerPC и неко­то­рые дру­гие ар­хи­тек­ту­ры. Scratchbox вклю­ча­ет на­сколь­ко на­бо­ров раз­ра­бот­чи­ка [development kits, devkits], ко­то­рые со­дер­жат все необ­хо­ди­мое для сбор­ки при­ло­жений той или иной плат­фор­мы, так что про­грам­мы, со­б­ран­ные в Scratchbox, мо­гут сра­зу уста­нав­ли­вать­ся на со­от­вет­ствую­щие це­ле­вые уст­рой­ства. Но это не все. Бла­го­да­ря ин­те­гра­ции с Qemu, про­грам­мы, со­б­ран­ные, на­при­мер, для ARM, мож­но за­пускать для от­лад­ки и тести­ро­вания непо­сред­ствен­но на ва­шей локаль­ной ма­шине с про­цес­со­ром x86. При этом госте­вая про­грам­ма вы­пол­ня­ет­ся не в окне Qemu, а в хост-систе­ме (ра­зу­ме­ет­ся, с ог­раничения­ми, на­ло­жен­ными «пе­сочницей» Scratchbox). Scratchbox ис­поль­зу­ет­ся как стан­дарт­ное сред­ство раз­ра­бот­ки для плат­форм ARM Linux Internet Platform и Maemo.

Для зна­ком­ства со Scratchbox про­ще все­го восполь­зо­вать­ся ди­ст­ри­бу­ти­вом, ко­то­рый рас­про­стра­ня­ет­ся вме­сте с Maemo SDK (и хо­тя са­ма Maemo, су­дя по все­му, бу­дет по­гло­ще­на MeeGo, прин­ци­пы кросс-плат­фор­мен­ной раз­ра­бот­ки от это­го вряд ли из­ме­нят­ся). Ком­пания Nokia сде­ла­ла все воз­мож­ное для уп­ро­щения уста­нов­ки и на­строй­ки Scratchbox и Qemu, и да­же рас­про­стра­ня­ла го­то­вые на­стро­ен­ные об­ра­зы вир­ту­аль­ных ма­шин. В ре­зуль­та­те мы по­лу­ча­ли эму­ля­тор внут­ри эму­ля­то­ра, ко­то­рый, бла­го­да­ря про­из­во­ди­тель­но­сти со­вре­мен­ных ПК, мог ра­бо­тать бы­ст­рее, чем це­ле­вое уст­рой­ство. Вир­ту­аль­ная ма­ши­на Qemu-ARM, вы­пол­няю­щая­ся внут­ри вир­ту­аль­ной ма­ши­ны VMware, ра­бо­таю­щей в Windows... Гля­дя на та­кое, неволь­но за­да­ешь се­бе во­прос, а не яв­ля­ет­ся ли вся на­ша Все­лен­ная вирту­аль­ной ма­ши­ной внут­ри ка­кой-нибудь дру­гой вир­ту­аль­ной ма­ши­ны? Ес­ли это так, то бу­дем на­де­ять­ся, что на­ша ма­ши­на за­про­грам­ми­ро­ва­на луч­ше, чем Qemu, и мы не вы­ле­тим на са­мом ин­те­рес­ном месте из-за ошиб­ки сег­мен­та­ции.

Про­бу­ем в де­ле

Как бы там ни бы­ло, мы уста­но­вим Maemo Scratchbox на жи­вом ком­пь­ю­те­ре, тем бо­лее что это не труднее, чем за­пустить вир­ту­аль­ную ма­ши­ну. Един­ствен­ная слож­ность, с ко­то­рой вы мо­же­те столк­нуть­ся, за­клю­ча­ет­ся в том, что эму­ля­тор и ин­ст­ру­мен­та­рий, по­став­ляе­мый Nokia, рас­счи­та­ны на 32‑бит­ные систе­мы (уста­нов­ка на x64 в прин­ци­пе воз­мож­на, но со­пря­же­на с неко­то­ры­ми труд­но­стя­ми). Под­роб­ная ин­ст­рук­ция по уста­нов­ке Maemo SDK, в том чис­ле и Scratchbox, доступ­на по ад­ре­су http://wiki.maemo.org/Documentation/Maemo5_Final_Installation. Сам Scratchbox уста­нав­ли­ва­ет­ся с по­мо­щью скрип­та maemo-scratchbox-install_5.0.sh (доступ к нему мож­но по­лу­чить, на­чав со страницы http://maemo.org/development/sdks/). Он уста­нав­ли­ва­ет только сре­ду Scratchbox, но не ком­понен­ты devkits, ко­то­рые тре­бу­ют­ся для сбор­ки при­ло­жений для ARM. Для их до­бав­ления нам по­на­до­бит­ся скрипт maemo-sdk-install_5.0.sh, ко­то­рый мож­но за­гру­зить с той же страницы. В про­цес­се уста­нов­ки оба скрип­та ска­чи­ва­ют тре­буе­мые ком­понен­ты из Се­ти, так что по­за­боть­тесь о досту­пе к Ин­тернету. Скрипт maemo-scratchbox-install_5.0.sh сле­ду­ет выпол­нять в ре­жи­ме root, тогда как скрипт maemo-sdk-install_5.0.sh – в ре­жи­ме обыч­но­го поль­зо­ва­те­ля. Для лю­би­те­лей гра­фи­че­ских ин­тер­фей­сов есть также еди­ный гра­фи­че­ский ин­стал­ля­тор.

По­ми­мо Maemo SDK, на ваш ком­пь­ю­тер бу­дут уста­нов­ле­ны несколь­ко средств раз­ра­бот­ки для про­цес­со­ров ARM и x86. Вы­бе­ри­те пункт «Runtime Environment + All Dev Packages» в ме­ню уста­нов­ки, в ре­зуль­та­те че­го бу­дут уста­нов­ле­ны все ком­понен­ты, необ­хо­ди­мые для раз­ра­бот­ки ARM.

Да­лее бу­дем счи­тать, что Scratchbox уста­нов­лен в ди­рек­то­рию /scratchbox. По­сле за­вер­шения уста­нов­ки скоман­дуй­те:

sudo /scratchbox/sbin/sbox_adduser ва­ше_имя_поль­зо­ва­те­ля

Вый­ди­те из сис­те­мы и вой­ди­те вновь, что­бы из­ме­не­ния вступи­ли в си­лу. Сер­вер Scratchbox за­пус­ка­ет­ся ко­ман­дой

sudo /scratchbox/sbin/sbox_ctl start

Да­лее, ско­ман­дуй­те

/scratchbox/login

И – ура! Мы по­па­ли в сре­ду Scratchbox. При­гла­шение коман­дой стро­ки (рис. 1) со­дер­жит имя це­ле­вой ар­хи­тек­ту­ры, для ко­то­рой на­стро­ен Scratchbox. Что­бы вы­брать дру­гую це­ле­вую ар­хи­тек­ту­ру и на­бор раз­ра­бот­чи­ка, нуж­но за­пустить ути­ли­ту sb-menu (рис. 2), что и со­ве­ту­ет сде­лать Scratchbox.

По­ми­мо воз­мож­но­сти вы­бо­ра це­ле­вой архи­тек­ту­ры и на­бо­ров раз­ра­бот­чи­ка, ути­ли­та по­зво­ля­ет ука­зать CPU Transparency – ме­тод эму­ля­ции це­ле­во­го про­цес­со­ра. Мы вы­би­ра­ем qemu-arm-sb. Те­перь про­грам­мы, со­б­ран­ные для ARM, мож­но за­пускать из команд­ной стро­ки Scratchbox. Ес­ли вы за­бу­де­те вы­ста­вить ме­тод эму­ля­ции про­цес­со­ра, по­пыт­ка за­пустить со­б­ран­ную про­грам­му в ва­шей систе­ме при­ве­дет к вы­во­ду со­об­щения ‘SBOX_CPUTRANSPARENCY_METHOD not set’.

Да­вай­те осмот­рим­ся по сто­ро­нам. К на­шим услу­гам ком­пиля­тор GCC, ко­то­рый со­би­ра­ет про­грам­мы для ARM (при усло­вии, что в окне sb-menu бы­ла вы­бра­на имен­но эта плат­фор­ма), от­лад­чик Gdb, на­бор про­грамм для ра­бо­ты с Perl, па­ке­ты Automake/Autoconf, тек­сто­вый ре­дак­тор Vi (ес­ли вы рань­ше пренеб­ре­га­ли изу­чением его команд, у вас поя­ви­лась еще од­на при­чи­на для то­го, что­бы, на­конец, их вы­учить) и мно­же­ство мел­ких вспо­мо­га­тель­ных про­грамм. По­ми­мо про­че­го, нам доступ­на и ути­ли­та apt-get, так что пе­ре­чень уста­нов­лен­ных при­ло­жений мож­но рас­ши­рить.

Ес­ли мы те­перь ском­пи­ли­ру­ем и за­пустим про­грам­му helloworld.c (мож­но, я обой­дусь без листин­га?), то уви­дим то, что и ожи­да­ли. Да­же не ве­рит­ся, что мы со­бра­ли про­грам­му для ино­род­но­го про­цес­со­ра. Что­бы убе­дить­ся, что эму­ля­ция ARM дей­стви­тель­но ра­бо­та­ет, восполь­зу­ем­ся коман­дой file. Ее вы­вод дол­жен вы­гля­деть при­мер­но так:

a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/
Linux 2.6.14, dynamically linked (uses shared libs), not stripped

Те­перь мож­но вздох­нуть с об­лег­чением. Ском­пи­ли­ро­вав про­грам­му helloworld.c с клю­чом -S, мы по­лу­чим код про­грам­мы на ас­семб­ле­ре для ARM (рис. 3).

Сре­да Scratchbox по­зво­ля­ет на­шим про­грам­мам, со­б­ран­ным для ARM, по­лу­чать доступ ко мно­гим уст­рой­ствам систе­мы – на­при­мер, к зву­ко­вым /scratchbox/dev/dsp и /scrachbox/dev/mixer. Ес­ли по умол­чанию поль­зо­ва­тель Scratchbox не име­ет досту­па к фай­лам этих уст­ройств, его нуж­но от­крыть с по­мо­щью команд из­менения прав досту­па в хост-систе­ме (fakeroot внут­ри са­мо­го Scratchbox нам тут не по­мо­жет).

На­бор доступ­ных биб­лио­тек за­ви­сит от вы­бран­ных devkit’ов. К на­шим услу­гам на­бо­ры debian-etch, debian-lenny, debian-sarge, apt-https, doctools, git, perl, qemu и svn. Как вы уже по­ня­ли, па­ке­ты мож­но ком­биниро­вать (это де­ла­ет­ся в про­грам­ме sb-menu), в ре­зуль­та­те че­го в систе­му уста­нав­ли­ва­ют­ся со­от­вет­ствую­щие биб­лио­те­ки и про­грам­мы. Я ис­поль­зо­вал на­бор debian-lenny+qemu. В этом ва­ри­ан­те, по­ми­мо стан­дарт­ной биб­лио­те­ки вре­мени вы­полнения, мож­но ис­поль­зо­вать ncurses и X11.

Scratchbox по­зво­ля­ет тести­ро­вать и от­ла­жи­вать гра­фи­че­ские при­ло­жения (и бы­ло бы стран­но, ес­ли бы не по­зво­ля­л, учи­ты­вая, что кон­соль, мяг­ко го­во­ря, не очень по­пу­ляр­на на мо­биль­ных уст­рой­ствах). Что­бы ра­бо­тать с Scratchbox и Maemo SDK безо вся­ких про­блем, мы уста­но­вим X-сер­вер Xephyr (он на­вер­ня­ка есть в ре­по­зи­то­ри­ях ва­ше­го ди­ст­ри­бу­ти­ва). Xephyr мож­но за­пустить коман­дой

Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -kb &

Ко­ман­до­вать сле­ду­ет за пре­де­ла­ми Scratchbox. Мы за­пус­ти­ли Xephyr на вто­ром дис­плее. Пе­рей­дем те­перь в Scratchbox и присво­им пе­ре­мен­ной ок­ру­же­ния DISPLAY зна­че­ние :2.0:

export DISPLAY=:2.0

Те­перь из ко­манд­ной стро­ки Scratchbox мож­но за­пус­кать гра­фиче­ские про­грам­мы (рис. 4).

Scratchbox сам по се­бе

Ес­ли вы не хо­ти­те поль­зо­вать­ся систе­мой Scratchbox в со­ставе Maemo SDK, мо­же­те уста­но­вить ее са­мо­стоя­тель­но. С сай­та про­ек­та (http://www.scratchbox.org) мож­но за­гру­зить ис­ход­ные тек­сты Scratchbox и на­бо­ров раз­ра­бот­чи­ка и го­то­вые па­ке­ты Debian.

Слож­но­сти способны возник­нуть при на­строй­ке Scratchbox. Па­кет scratchbox имееся в двух ва­ри­ан­тах: ста­рый scratchbox 1.x и но­вый scratchbox 2, ко­то­рый раз­ра­ба­ты­ва­ет­ся при поддерж­ке Nokia. Мы рас­смот­рим на­строй­ку scratchbox 2. Пе­ред этим, по­ми­мо са­мо­го па­ке­та, нуж­но уста­но­вить Qemu и систе­му сбор­ки для ARM. В ка­че­стве по­следней мы ис­поль­зу­ем ин­ст­ру­мен­та­рий CodeSourcery для про­цес­со­ров ARM, о ко­то­ром бу­дет ска­за­но ниже.

Пре­ж­де все­го, нуж­но вы­звать ути­ли­ту sb2-init:

sb2-init -c /usr/bin/qemu-arm armv7 /usr/local/arm-2008q3/bin/arm-none-linux-gnueabi-gcc

Здесь armv7 – це­ле­вая ар­хи­тек­ту­ра про­цес­со­ра. Ути­ли­ту sb2‑init сле­ду­ет вы­зы­вать из ди­рек­то­рии, ко­то­рая бу­дет корневым ка­та­ло­гом «пе­сочницы» Scratchbox. Для из­менения па­ра­мет­ров уже на­стро­ен­ной систе­мы мож­но восполь­зо­вать­ся ути­ли­той sb2‑config. На­при­мер, вы­зов

sb2-config -d armvt

за­ме­ня­ет це­ле­вую ар­хи­тек­ту­ру. Те­перь ко­ман­ду­ем

sb2 -R

и ока­зы­ва­ем­ся в «пе­соч­ни­це» Scratchbox. В дан­ном слу­чае sb2 ра­бо­та­ет в ре­жи­ме обо­лоч­ки. Да­лее все про­ис­хо­дит так, как в обыч­ной Linux-сис­те­ме. Про­грам­му sb2 мож­но вы­зы­вать и в режи­ме ко­манд­ной стро­ки, на­при­мер:

sb2 ./configure --prefix=/usr/local/arm-2008q3/sb2 make

и так да­лее.

От­лад­ка при­ло­жений мо­жет вы­пол­нять­ся на хост-ком­пь­ю­те­ре с ис­поль­зо­ванием спе­ци­аль­ной вер­сии от­лад­чи­ка Gdb, адап­ти­рован­ной для ра­бо­ты с Qemu. Как и в слу­чае Maemo SDK, от­лад­ка вы­пол­ня­ет­ся в уда­лен­ном ре­жи­ме. Сна­ча­ла с по­мо­щью коман­ды sb2‑qemu-gdbserver-prepare мы за­пуска­ем сер­вер от­лад­ки со­вме­ст­но с эму­ля­то­ром, за­тем – кли­ент от­лад­чи­ка, адап­ти­ро­ван­ный к ра­бо­те с ARM, в на­шем слу­чае – тот, ко­то­рый вхо­дит в по­ставку CodeSourcery.

Слож­но­сти кросс-плат­фор­мен­ной сбор­ки

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

На­бо­ры Scratchbox Devkits со­дер­жат, по­ми­мо про­че­го, вер­сии биб­лио­тек, ском­пи­ли­ро­ван­ных на це­ле­вых плат­фор­мах для це­ле­вых сис­тем, так что при сбор­ке на ПК про­грам­ма сра­зу ком­по­ну­ет­ся «пра­виль­но». Не­сколь­ко го­то­вых на­бо­ров вхо­дят в по­став­ку Scratchbox, а на сай­те про­ек­та (http://www.scratchbox.org) мож­но най­ти ин­ст­рук­цию по соз­да­нию но­вых на­бо­ров. Фраг­мент фай­ло­вой сис­те­мы, со­дер­жа­щий ми­ни­маль­ный на­бор фай­лов сре­ды вре­ме­ни вы­пол­не­ния, не­об­хо­ди­мых для за­пус­ка про­грам­мы, час­то име­ну­ет­ся sysroot. Так же на­зы­ва­ет­ся пе­ре­мен­ная, со­держа­щая путь к кор­ню це­ле­вой фай­ло­вой сис­те­мы и еще неко­то­рые ве­щи, но ко­гда про­грам­ма ус­та­нов­ки спра­ши­ва­ет вас, нуж­но ли ус­та­но­вить sysroot, знай­те: вам все­го лишь пред­ла­га­ют ус­та­но­вить сре­ду вре­ме­ни вы­пол­не­ния.

Где же на­ши фай­лы?

Scratchbox – мно­го­поль­зо­ва­тель­ская сис­те­ма. Ес­ли кор­не­вая ди­рек­то­рия Scratchbox име­ет имя /scratchbox, то на­строй­ки поль­зо­ва­те­ля user_name хра­нят­ся в ди­рек­то­рии /scratchbox/users/user_name, а его до­маш­ней ди­рек­то­ри­ей в сре­де Scratchbox бу­дет /scratchbox/users/user_name/home/user_name.

От­лад­ка в Scratchbox

Ра­бо­тая в Scratchbox с про­грам­ма­ми, пред­назна­чен­ны­ми для ARM, не­труд­но за­быть о том, что на са­мом де­ле у нас про­цес­сор x86. Од­на­ко, ко­гда мы при­сту­па­ем к от­лад­ке при­ло­же­ния, ог­ра­ни­че­ния эму­ля­ции на­по­ми­на­ют нам об этом: мы не мо­жем от­ла­жи­вать про­грам­му, пред­на­зна­чен­ную для ARM, из ко­манд­ной стро­ки. Нам при­дет­ся сна­ча­ла за­пус­тить сер­вер Qemu в ре­жи­ме от­лад­ки (на­пом­ню, что в Qemu встро­ен от­лад­чи­к), а за­тем под­клю­чить­ся к это­му сер­ве­ру с по­мо­щью про­грам­мы Gdb, как к уда­лен­ной ма­ши­не. До­пус­тим, у нас есть про­грам­ма hello, ском­пи­ли­ро­ван­ная для плат­фор­мы ARM с клю­чом -g (то есть с от­ладоч­ной ин­фор­ма­ци­ей). В этом слу­чае сер­вер за­пус­ка­ет­ся из ко­манд­ной стро­ки Scratchbox:

qemu-arm-sb -g 1212 hello

Здесь 1212 – но­мер пор­та, по ко­то­ро­му кли­ент от­лад­ки со­еди­ня­ет­ся с сер­ве­ром, а hello – имя ис­пол­ни­мо­го фай­ла от­ла­жи­вае­мой про­грам­мы. Те­перь в ок­не тер­ми­на­ла Scratchbox мы за­пус­ка­ем про­грам­му gdb (или gdbtui).

В ко­манд­ной стро­ке от­лад­чи­ка вво­дим следующие ко­ман­ды:

(gdb) file hello
(gdb) target remote :1212

По­сколь­ку сер­вер от­лад­ки вы­пол­ня­ет­ся на той же ма­ши­не, что и кли­ент, мы ука­зы­ва­ем толь­ко порт, но не ад­рес. В ре­зуль­та­те про­грам­ма за­гру­же­на и го­то­ва к даль­ней­шей от­лад­ке, ко­то­рая ана­ло­гич­на про­цес­су от­лад­ки ло­каль­но­го фай­ла (рис. 5).

GNU ARM

Про­ект GNU ARM (http://www.gnuarm.com) пре­достав­ля­ет нам стандарт­ный на­бор ин­ст­ру­мен­тов GNU для раз­ра­бот­ки про­грамм под ARM-про­цес­сор (его мож­но ис­поль­зо­вать и в со­ста­ве па­ке­та раз­ра­бот­чи­ка для Scratchbox). Ес­ли вы не хо­ти­те тра­тить вре­мя на уста­нов­ку Scratchbox, GNU ARM – ваш вы­бор. Для уста­нов­ки GNU ARM доста­точ­но рас­па­ко­вать ар­хив дво­ич­ных фай­лов, при­чем доступ­ных не толь­ко для Linux x86, но и под Cygwin и Mac OS. В ре­зуль­та­те сбор­ки про­грам­мы в GNU ARM вы по­лу­чи­те ста­ти­че­ски ском­по­но­ван­ный 32‑бит­ный файл в фор­ма­те ELF, так что его мож­но вы­полнить на лю­бой систе­ме Linux для ARM. Ес­ли к ин­ст­ру­мен­там GNU ARM мы до­ба­вим в на­бор от­лад­чик Gdb и эму­ля­тор Qemu, то по­лу­чим ана­лог Scratchbox для ра­бо­ты из-под Windows или Mac, хо­тя ис­поль­зо­вать Scratchbox все же удобнее: мно­гие ути­ли­ты, пред­на­зна­чен­ные спе­ци­аль­но для Linux, не смо­гут ра­бо­тать в чу­жих систе­мах.

В ка­че­стве стан­дарт­ной биб­лио­те­ки вре­мени вы­полнения в GNU ARM ис­поль­зу­ет­ся Newlib, раз­ра­ба­ты­вае­мая Red Hat. Ста­ти­че­ское свя­зы­вание про­грам­мы с биб­лио­те­кой вре­мени вы­полнения яв­ля­ет­ся одним из тре­бо­ваний стан­дар­та EABI (Embedded Application Binary Interface), дво­ич­но­го ин­тер­фей­са для встро­ен­ных систем, на ко­то­ром осно­ван GNU ARM. Сле­до­вание стан­дар­ту обес­пе­чи­ва­ет дво­ич­ную со­вмести­мость ме­ж­ду про­грамм­ны­ми ком­понен­та­ми, со­б­ран­ны­ми с ис­поль­зо­ванием раз­лич­ных систем раз­ра­бот­ки. Осо­бен­но­сти стан­дар­та ори­ен­ти­ро­ва­ны на при­ло­жения, ра­бо­таю­щие на «го­лом же­ле­зе», то есть без вся­кой опе­ра­ци­он­ной систе­мы. Так, EABI по­ощ­ря­ет (а иногда и де­ла­ет обя­за­тель­ным) ста­ти­че­ское свя­зы­вание при­ло­жения с биб­лио­те­ка­ми и до­пуска­ет на­ли­чие в ко­де при­ви­ле­ги­ро­ван­ных ин­ст­рук­ций, ко­то­ры­ми обыч­но поль­зу­ет­ся толь­ко яд­ро ОС. По этой при­чине при­ло­жения EABI не все­гда мо­гут ра­бо­тать в Linux, хо­тя но­вей­шие ARM-ди­ст­ри­бу­ти­вы от Debian са­ми осно­ва­ны на EABI.

Sourcery G++

Па­кет Sourcery G++ (http://www.codesourcery.com) пред­став­ля­ет со­бой сред­ство кросс-плат­фор­мен­ной сбор­ки при­ло­жений на осно­ве ин­ст­ру­мен­та­рия GNU, ин­тег­ри­ро­ван­ной сре­ды Eclipse и несколь­ких ин­ст­ру­мен­тов, до­бав­лен­ных раз­ра­бот­чи­ка­ми па­ке­та. Оно су­ще­ству­ет в ва­ри­ан­тах для Linux и Windows (по­следний, есте­ствен­но, на осно­ве MinGW). В от­ли­чие от все­го рас­смот­ре­нного вы­ше, Sourcery G++ не бес­пла­тен; тем не менее, мож­но взять бес­плат­ную проб­ную вер­сию и сравнить воз­мож­но­сти Sourcery G++ с неком­мер­че­ски­ми кон­ку­рен­та­ми. Сре­ди мно­го­чис­лен­ных плат­форм, ко­то­рые под­дер­жи­ва­ет Sourcery G++, есть и ARM GNU/Linux (пол­но­цен­ный Linux на про­цес­со­ре ARM). Эту вер­сию Sourcery G++ мож­но ис­поль­зо­вать, в том чис­ле, и для сбор­ки яд­ра Linux. Вер­сия для плат­фор­мы ARM EABI по­зво­ля­ет со­би­рать про­грам­мы для ра­бо­ты на «го­лом же­ле­зе». Эта вер­сия со­дер­жит свой соб­ствен­ный эму­ля­тор ARM, ко­то­рый мож­но ис­поль­зо­вать и для от­лад­ки.

В ка­че­стве сер­ве­ра от­лад­чи­ка в Sourcery G++ ис­поль­зу­ет­ся про­грам­ма gdbserver, ко­то­рая долж­на быть уста­нов­ле­на на це­ле­вой плат­фор­ме. Взаи­мо­дей­ствие ме­ж­ду локаль­ным от­лад­чи­ком GDB и сер­ве­ром от­лад­ки про­ис­хо­дит так же, как бы­ло опи­са­но вы­ше для Scratchbox. С по­мо­щью сво­его соб­ствен­но­го скрип­та от­лад­ки мож­но нау­чить Sourcery G++ ис­поль­зо­вать сер­вер от­лад­ки из Qemu, или сер­вер OpenOCD для встраи­вае­мых уст­ройств. Соб­ствен­но, са­ми раз­ра­бот­чи­ки Sourcery G++ не скры­ва­ют, что основ­ная их за­слу­га – сбор­ка и на­лад­ка па­ке­тов, доступ­ных всем в ви­де ис­ходников. Ри­чард Стол­л­мен дол­жен одоб­рять та­кую мо­дель!

Са­мое ин­те­рес­ное в па­ке­те для нас, по­жа­луй, это но­вые вер­сии ори­ен­ти­ро­ван­ных на ARM ин­ст­ру­мен­тов GNU (для сравнения, GNU ARM «за­мер» на уровне 2006 го­да). По­сколь­ку это ин­ст­ру­мен­ты GNU, вы мо­же­те ко­пи­ро­вать и ис­поль­зо­вать их в лю­бых про­ек­тах, не всту­пая в кон­фликт со сво­ей со­ве­стью (ес­ли она во­об­ще что-то го­во­рит вам по по­во­ду ко­пи­ро­вания про­грамм). К это­му сто­ит до­ба­вить биб­лио­те­ку glibc, со­б­ран­ную с ис­поль­зо­ванием за­го­ло­воч­ных фай­лов из бо­лее но­вых вер­сий ядер.

SDK, соз­дан­ные про­из­во­ди­те­ля­ми мо­биль­ных уст­ройств, обыч­но скры­ва­ют от поль­зо­ва­те­ля де­та­ли ра­бо­ты плат­фор­мы. Тем не ме­нее, зна­ние этих де­та­лей не толь­ко раз­ви­ва­ет мысль, но и (воз­мож­но) по­зво­лит вам дос­тичь уров­ня ле­ген­дар­но­го про­грам­ми­ста Ме­ла.

Це­ни­те­лям кра­си­во­го ас­семб­ле­ра

Как из­вест­но, на­стоя­щие про­грам­ми­сты пи­шут про­грам­мы ра­ди кра­со­ты. Са­мые же на­стоя­щие – ра­ди той кра­со­ты, ко­то­рую мож­но уви­деть толь­ко в ди­зас­семб­ле­ре (http://rixstep.com/2/2/20071015,01.shtml – клас­си­че­ский при­мер). По­смот­ри­те на про­стую реа­ли­за­цию функ­ции sign() на язы­ке C:

int sign(int x) {
 if (x > 0)
 return 1;
 if (x < 0)
 return -1;
 return 0;
 }

Сколь­ко пе­ре­хо­дов в ас­семб­лер­ном эк­вива­ленте этой функ­ции? Ес­ли вы ком­пи­ли­руе­те функ­цию с по­мо­щью GCC для ARM с вклю­ченным фла­гом -O3, от­ве­т будет «ни од­но­го»:

cmp r0, #0
mov r0, #1
movgt pc, lr
mvn r0, #0
movge r0, #0
mov pc, lr

Пер­вая строч­ка ко­да срав­ни­ва­ет со­дер­жи­мое ре­ги­ст­ра r0 (пе­ре­да­ющего ар­гу­мент функ­ции) с ну­лем. Заметь­те суф­фик­сы (в сис­те­ме ко­манд ARM – ско­рее пре­фик­сы) ус­лов­но­го вы­пол­не­ния при ко­ман­дах mov, ма­ни­пу­ля­ции с ре­ги­ст­ра­ми PC (ад­рес сле­дую­щей вы­пол­няе­мой ин­ст­рук­ции) и LR (ад­рес воз­вра­та) для вы­хо­да из функ­ции. Однако ва­ри­ант

int sign(int x) {
 return (x > 0) - (x < 0);
 }

про­из­ве­дет код на од­ну ин­ст­рук­цию ко­роче (впро­чем, на­счет вы­иг­ры­ша по вре­ме­ни я не уве­рен).