Tartalomjegyzék

Ugrás az olvasói útmutatóhoz

I. RÉSZ – AArch64: alkalmazásszintű ARM assembly Linux alatt

1 Olvasói útmutató: kinek szól a könyv, és hogyan olvasd

• 1.1 A könyv használata: C-előismeret, tanulási kimenetek, belépési pontok

2 Bevezetés: hardver, ISA és a gép nyelve

• 2.1 Miért assembly: amit a C elrejt
• 2.2 Számrendszerek és bitszintű reprezentáció
• 2.3 Számítógép-architektúra fogalmai: ISA, mikroarchitektúra, regiszter, busz
• 2.4 Az ARM család áttekintése: profilok, verziók és a könyv két része
• 2.5 C fordítási láncolat és hova kerül az assembly

3 Fejlesztői környezet és labor: eszközlánc, QEMU, build-munkafolyamat

• 3.1 Labor-alapkörnyezet: eszközlánc telepítése és verifikáció
• 3.2 Assemble-link-run munkafolyamat natív és cross környezetben
• 3.3 Opcionális fizikai hardver: Raspberry Pi 64-bit módban
• 3.4 Szerkesztő és debug-eszközök: GDB, objdump, readelf első look

4 Az első program: regiszterek, ELF és a Linux syscall-felszín

• 4.1 Az A64 regiszterkészlet áttekintése
• 4.2 Hello world tisztán assemblyben: szekciók, _start, syscall hívás
• 4.3 Az ELF formátum alapjai és a program életciklusa
• 4.4 Linux syscall-konvenció AArch64-en

5 Adatmozgatás, aritmetika és állapotjelzők

• 5.1 MOV-variánsok és immediate-kódolás
• 5.2 Egész aritmetika: ADD/SUB/MUL/DIV és a kettes komplemens viselkedése
• 5.3 Az NZCV állapotjelzők és eredetük
• 5.4 Feltételes végrehajtás: CSET/CSEL és feltételkódok

6 Vezérlésátadás: elágazás és ciklusok C-szemmel

• 6.1 Feltétel nélküli és feltételes elágazás
• 6.2 C if/else és switch leképezése assemblyre
• 6.3 Ciklusszervezés: while/for/do-while mintázatok assemblyben
• 6.4 Hívás és visszatérés: BL/RET bevezető mintája

7 Memóriacímzés és adatszerkezetek

• 7.1 Load/store címzési módok
• 7.2 Tömbök és indexelt elérés assemblyben
• 7.3 Struktúrák, igazítás és mezőelérés
• 7.4 Bájtsorrend: endianness és miért releváns a határon
• 7.5 Statikus és dinamikus memória: .bss, .data és egyszerű allokáció

8 Függvények és az AAPCS64 hívási konvenció

• 8.1 A stack frame felépítése és a verem iránya
• 8.2 Az AAPCS64 regiszterszerződés
• 8.3 Prológus és epilógus: regisztermentés és keretkezelés
• 8.4 Rekurzív függvények assemblyben
• 8.5 Több visszatérési érték és struktúra-visszaadás szerződése

9 Bitmanipuláció és logikai műveletek

• 9.1 Logikai alapműveletek és bitmaszkolás
• 9.2 Shift és rotate: LSL/LSR/ASR/ROR gyakorlati mintázatok
• 9.3 Bitfield-utasítások: BFI/UBFX/SBFX és csomagolt adatszerkezetek
• 9.4 Gyakorlati bitmanipulációs feladatok: popcount, parity, bitfordítás

10 C-assembly interoperabilitás és fordítóprogram-elemzés

• 10.1 Inline assembly GCC-ben
• 10.2 Assembly függvény hívása C-ből és C hívása assemblyből
• 10.3 Fordítói optimalizálási szintek hatása a generált kódra
• 10.4 Tipikus fordítói mintázatok felismerése

11 Debugging, disassembly és instrumentáció

• 11.1 GDB assembly szinten
• 11.2 Disassembly objdump/readelf-fel
• 11.3 Hibakeresési esettanulmány: szegmentálási hiba gyökérokának megtalálása
• 11.4 Egyszerű instrumentáció: ciklusszámlálás és időmérés

12 Lebegőpontos aritmetika és NEON/SIMD vektorizáció

• 12.1 A lebegőpontos regiszterkészlet és az IEEE 754 ábrázolás
• 12.2 Skaláris lebegőpontos utasítások
• 12.3 A NEON regiszterkészlet és adatelrendezés
• 12.4 Vektorizált összeadás/szorzás: egy skaláris ciklus NEON-átirata
• 12.5 NEON-gyorsulás mérése és korlátai

13 Teljesítmény-tudatos kód: cache, pipeline és mérés

• 13.1 Cache-hierarchia és a memóriahozzáférési minták hatása
• 13.2 Pipeline alapfogalmak és adatfüggőségi akadályok
• 13.3 Branch prediction és elágazás-szervezés hatása
• 13.4 Mikrobenchmark készítése és eredmények értelmezése

14 Biztonsági szemlélet: verem, védelem és ROP

• 14.1 Verem-túlcsordulás mechanizmusa assembly szinten
• 14.2 Védelmi mechanizmusok: canary, ASLR, NX/DEP, PAC
• 14.3 ROP-lánc felismerése és miértje
• 14.4 Biztonságos assembly- és C-interop gyakorlat

15 Záróprojekt I: teljesítménykritikus assembly modul C programban

• 15.1 Projektspecifikáció: feladat, interfész és mérési terv
• 15.2 Megvalósítás: az assembly modul implementációja
• 15.3 Mérés és validáció
• 15.4 Visszacsatolás és auditmódszer

II. RÉSZ – Cortex-M: bare-metal mikrokontroller-programozás

16 Thumb-2, a Cortex-M futási modell és a minimal runtime

• 16.1 A-profile és M-profile különbségei: miért más a Cortex-M
• 16.2 Thumb-2 ISA áttekintés
• 16.3 Memóriatérkép és a bare-metal futási modell
• 16.4 Reset és boot-folyamat: vektortábla
• 16.5 Linker script alapjai: szekciók memóriába helyezése
• 16.6 Startup kód: .data másolása, .bss törlése
• 16.7 Firmware build és QEMU-betöltés munkafolyamat

17 Kivételek és megszakítások: NVIC

• 17.1 A Cortex-M kivételmodell: prioritás és vektortábla-bejegyzések
• 17.2 NVIC konfiguráció: engedélyezés és prioritás
• 17.3 ISR írása: C és assembly vegyesen
• 17.4 Megszakítás-latencia mérése és korlátai

18 Memory-mapped perifériák és GPIO

• 18.1 Memory-mapped I/O alapelve
• 18.2 GPIO közvetlen vezérlése: bitbanging
• 18.3 Periféria-regiszter absztrakció C struktúrával

19 Megszakítás-vezérelt I/O és driver minta

• 19.1 Polling versus interrupt-vezérelt I/O
• 19.2 Egyszerű UART driver: inicializálás, küldés/vétel megszakítással
• 19.3 Timer-alapú időzítés és periodikus feladatok

20 Záróprojekt II: interrupt-vezérelt Cortex-M firmware-modul

• 20.1 Projektspecifikáció: periféria, megszakítás-logika és mérési terv
• 20.2 Megvalósítás: driver és ISR integrálása a minimal runtime-ba
• 20.3 Mérés, validáció és a QEMU-alapú teszt reprodukálhatósága
• 20.4 Auditszempontok bare-metal firmware-hez

1 Olvasói útmutató: kinek szól a könyv, és hogyan olvasd

1.1 A könyv használata: C-előismeret, tanulási kimenetek, belépési pontok

Motiváció

Mielőtt bármelyik fejezetbe belekezdenél, két kérdésre érdemes néhány perc alatt válaszolni: van-e meg a szükséges C-alapom, és hol érdemes belépnem a könyvbe. Ha ezt kihagyod, két tipikus veszteség ér: vagy olyan alfejezeteken rágsz át heteket, amelyeket már tudsz (például a számrendszereket), vagy olyan szerződéseket (hívási konvenció, NVIC-regiszterek) ugrasz át „ismerősnek tűnik” alapon, amelyeket a könyv később mindenhol feltételez. Ez az alfejezet ezért nem technikai tananyag, hanem útvonalterv: önellenőrző listát, konkrét tanulási kimeneteket és belépési pontokat ad.

Definíció: előismeret-küszöb és belépési pont

Előismeret-küszöb: a minimális, cselekvésben mérhető C-tudás (nem „közepes szintű C”, mert az nem mérhető), amellyel a könyv technikai alfejezetei a C nyelv újratanítása nélkül értelmezhetők.

Belépési pont: a könyvtérkép alfejezete, ahonnan az olvasó a meglévő tudásához igazítva kezdheti a tanulást — a küszöb mindenkire érvényes, a belépési pont csak a kezdőpozíciót választja meg.

Önellenőrző lista: a szükséges C-tudás

A következő állításoknak kell igaznak lennie rád. Ha valamelyik nem az, azt előbb pótolni kell; a könyv ezeket nem tanítja újra, csak használja.

• Mutató és tömb: meg tudsz írni egy függvényt, amely int tömböt és annak hosszát kapja, és mutatóaritmetikával (nem indexeléssel) járja be. Érted a különbséget int *p[4] és int (*p)[4] között.
• Struktúra és memórialayout: tudod, miért nem feltétlenül sizeof(struct) a mezők méreteinek összege, és miért számít a mezők sorrendje.
• Többfájlos build és Makefile: létre tudsz hozni legalább két .c és egy .h fájlból álló programot saját Makefile-lal, all és clean céllal; a fejlécbe deklarációt, egyetlen fordítási egységbe definíciót teszel, és érted, miért nem elég a #include: a linkernek a definíciót tartalmazó objektumra is szüksége van.
• Fordítási lánc fogalmi szinten: meg tudod mondani, mit csinál a preprocesszor, a fordító és a linker, és miért kapcsolódik össze két .o fájl egy futtatható állományba.
• Parancssor: otthonosan mozogsz shellben, fájlt másolsz, szövegszerkesztőt használsz, és nem riadsz meg egy nem nulla kilépési kódtól.

Ami nem része a küszöbnek: assembly, regiszterek, ISA, NEON/SIMD, megszakításkezelés, bare-metal fejlesztés, QEMU. Ezeket a könyv nulláról építi fel.

Tanulási kimenetek

Belépési pontok és átugorható szakaszok

Az átugorható szakaszok is alap-ISA-ismeretek: ha a kettes komplemens, a bináris jelölés vagy az ISA/mikroarchitektúra megkülönböztetése már biztos, a Számrendszerek és bitszintű reprezentáció és a Számítógép-architektúra fogalmai valóban kihagyható.

Az át nem ugorható szerződések más okból kötelezők, és útvonalanként különböznek:

Egyik sem a könyv saját konvenciója:

• Az AAPCS64 az Arm 64 bites architektúrájának eljáráshívási szabványa (Procedure Call Standard, PCS). Az argumentumok és eredmények átadását, valamint a hívásokon át megőrzendő gépállapotot rögzíti. A PCS a tágabb bináris alkalmazásinterfész (ABI) hívási szabályokat rögzítő része; az ABI ezen túl például az objektumformátumot és az adatábrázolást is szabályozza (Az AAPCS64 regiszterszerződés). A könyv AArch64-célján (Linux, little-endian, LP64) az alap AAPCS64 érvényes. Más platformok, például más operációs rendszerek ABI-jai erre építve saját kiegészítéseket és eltéréseket rögzíthetnek.
• Az NVIC az M-profile architektúra része, de hozzá implementáció- és panelspecifikus beállítások társulnak: a ténylegesen megvalósított megszakításvonalak száma, a prioritásmezők kihasznált bitjei és a perifériák IRQ-számai a konkrét magtól, SoC-tól és paneltől függenek.

Ezeket el kell választani a választott labor saját szerződésétől — például a QEMU-célgéptől (mps2-an385) és az azon érvényes perifériacímektől —, amely csak a könyv példáira érvényes. A választott útvonal szerződését azért kell tapasztalt olvasóként is végigvenni, mert az útvonal későbbi példái rá épülnek, nem azért, mert a könyv találta ki: az I. rész C-ből hívható assembly függvényei az AAPCS64-re, a II. rész megszakításos laborjai az AAPCS32-re és az NVIC-re.

A kizárólag Cortex-M-et tanuló olvasó kötelező PCS-belépője az AAPCS32 (Procedure Call Standard for the Arm Architecture), a 32 bites Arm architektúra, köztük az M-profile eljáráshívási szabványa. Az Az AAPCS64 regiszterszerződés ilyenkor hasznos összehasonlítás, de nem helyettesíti az AAPCS32-t: eltér a regiszterszélesség (32 vs. 64 bit), az argumentumregiszterek köre (R0–R3 vs. X0–X7), a hívott által megőrzendő regiszterek halmaza (R4–R11 vs. X19–X28) és a verem igazítási követelménye (nyilvános interfészen 8 vs. 16 bájt).

Hogyan használd a feladatokat és a megoldásokat

Ez az útmutató a könyv minden feladatsorára és megoldására érvényes; az alfejezetek nem ismétlik meg.

• Címkék. A feladatok háromféle címkét kapnak: a típusukat (magyarázó, implementációs, hibakeresési/mérési, integráló; néhány alfejezet ezek szűkebb változatát is használja, például verifikációs vagy szélsőérték-próba), a nehézségüket (alapszint, középszint, elmélyült) és a céljukat: mit erősít elsősorban az adott feladat. Ez lehet a fogalom megértésének ellenőrzése (megértés-ellenőrzés), egy ismétlődő eljárás begyakorlása (rutinépítés), vagy több fejezet tudásának összekapcsolása. A korábbi alfejezetek egy része csak a típust adja meg.
• Kétlépcsős megoldások. Ahol a megoldás két részre oszlik, előbb egy rövid segítség áll, amely irányt ad, de nem árulja el a választ, utána a teljes megoldás. Érdemes a segítségnél megállni, és csak akkor továbbolvasni, ha önállóan elakadtál.
• Futtatási feltételek. A laborok munkakönyvtára, build- és futtatóparancsa, valamint elvárt kimenete mindig az adott alfejezetben áll; ezeket az útmutató nem helyettesíti.

Kidolgozott példa: előismeret-önellenőrző build

Munkakönyvtár: ~/arm-labor/a64/a000/ — az alfejezet minden laborfájlja ide kerül, és minden parancs innen futtatandó (a könyvtárrendet a Labor-alapkörnyezet alfejezet írja le).

mkdir -p ~/arm-labor/a64/a000
cd ~/arm-labor/a64/a000

Az alábbi háromfájlos program a küszöb elemeit (mutató, struktúra, többfájlos build) gyakorolja: két külön fordítási egységből (lab-main.c, lab-sum.c) és egy közös fejlécből (lab-sum.h) áll. A fejléc a struct pair típust és a sum_values deklarációját adja, a függvény definíciója egyetlen fordítási egységben, a lab-sum.c-ben van. Célja nem a funkcionalitás, hanem hogy te tudd összeilleszteni és lefordítani.

/* lab-sum.h */
#ifndef LAB_SUM_H
#define LAB_SUM_H

struct pair { int key; int value; };

int sum_values(const struct pair *p, int n);   /* deklaráció */

#endif

/* lab-sum.c */
#include "lab-sum.h"

int sum_values(const struct pair *p, int n) {  /* definíció */
    int s = 0;
    for (const struct pair *q = p; q < p + n; ++q) s += q->value;
    return s;
}

/* lab-main.c */
#include <stdio.h>
#include "lab-sum.h"

int main(void) {
    struct pair v[3] = {{1,10},{2,20},{3,30}};
    printf("%d %zu\n", sum_values(v, 3), sizeof(struct pair));
    return 0;
}

A Makefile mindkét objektumot linkeli, és mindkét objektum függőségei között szerepel a fejléc:

# Makefile
CC = gcc
CFLAGS = -Wall -Wextra -O2 -std=c11
OBJS = lab-main.o lab-sum.o

.PHONY: all clean
all: lab-a000

lab-a000: $(OBJS)
    $(CC) $(CFLAGS) -o $@ $^

lab-main.o: lab-main.c lab-sum.h
    $(CC) $(CFLAGS) -c -o $@ $<

lab-sum.o: lab-sum.c lab-sum.h
    $(CC) $(CFLAGS) -c -o $@ $<

clean:
    rm -f lab-a000 $(OBJS)

Futtatás (target: x86_64 host, natív gcc; a kód hordozható, AArch64-en azonos kimenet várható):

make
./lab-a000
echo $?

Várt kimenet: 60 8, majd a kilépési állapot 0. Az 60 a három value összege; a 8 a struct pair mérete ezen az ABI-n (két 4 bájtos int, igazítás miatt hézag nélkül). A pontos méret ABI-függő; a sizeof kiíratása éppen ezért része az ellenőrzésnek.

Elfogadási próbák. A futó program önmagában még nem bizonyítja, hogy a többfájlos build szerkezete helyes. Két próbának is teljesülnie kell:

1. A definíció valóban a másik objektumban van. Linkeld a programot a lab-sum.o nélkül. Ez egy negatív próba: itt a nem nulla kilépési állapot az elvárt eredmény.

   make -B OBJS=lab-main.o
   echo "make kilépési állapot: $?"    # elvárt: nem nulla (GNU Make: 2)

   A -B kapcsoló kötelező. Egy sikeres make után a lab-a000 újabb, mint minden függősége, és a Make az időbélyegek alapján dönt: az OBJS lista megváltozása önmagában nem kényszerít új linkelést. A -B nélkül a parancs Nothing to be done for 'all'. üzenettel, 0-s állapottal érne véget, és a próba semmit sem bizonyítana. Ugyanezt a próbát a Make megkerülésével is elvégezheted: gcc -o lab-missing lab-main.o.

   Valódi linkerhibát kell kapnod, nem fordítási hibát: a lab-main.c a fejléc deklarációja miatt hibátlanul lefordul, csak a definíció hiányzik.

   gcc -Wall -Wextra -O2 -std=c11 -c -o lab-main.o lab-main.c
   gcc -Wall -Wextra -O2 -std=c11 -o lab-a000 lab-main.o
   /usr/bin/ld: lab-main.o: in function `main':
   lab-main.c:(.text.startup+0x39): undefined reference to `sum_values'
   collect2: error: ld returned 1 exit status
   make: *** [Makefile:10: lab-a000] Error 1
   make kilépési állapot: 2

   (A +0x39 eltolás fordítóverziótól és kapcsolóktól függ.) Ezután térj vissza a helyes objektumlistához, és ellenőrizd újra a kimenetet:

   make -B && ./lab-a000                # elvárt: 60 8

2. A fejléc módosítása az érintett objektumokat újrafordítja. Egy sikeres make után:

   touch lab-sum.h
   make

   Mindkét gcc -c sornak (lab-main.o és lab-sum.o) meg kell jelennie, majd a linkelésnek. Ellenpróbaként touch lab-sum.c után csak a lab-sum.o fordul újra.

A két eltéréstípust érdemes külön kezelni. Ha az összeg nem 60, vagy bármelyik elfogadási próba eltér a fentitől, a build szerkezete vagy a küszöb valamelyik eleme bizonytalan; azt pótolni kell a továbblépés előtt. Ha viszont csak a második szám tér el a 8-tól, az nem build-hiba, hanem a cél-ABI tulajdonsága. Ilyenkor azt kell ellenőrizni, hogy a kapott méret megfelel-e az adott ABI int-méretének és igazítási szabályának (két int mező, hézag nélkül: 2 * sizeof(int)).

Tipikus hibák és ellenpróbák

• Tünet: „értem a mutatókat”, de a q < p + n feltétel bizonytalan. Hipotézis: a mutatóaritmetika léptéke nem tiszta. Adatgyűjtés: írasd ki (char*)q - (char*)p értékét a ciklusban. Egy változtatás: cseréld a ciklust indexelésre, és hasonlítsd össze. Ellenőrzés: a két változat azonos eredményt adjon.
• Tünet: a Makefile „működik”, de a clean után nem épül újra. Hipotézis: hiányzó vagy hibás függőségi sor. Ellenőrzés: make -n száraz futtatással nézd meg, mit tenne.
• Tünet: a fejléc módosítása után a program régi viselkedést mutat, vagy a két objektum eltérő struct pair-t lát. Hipotézis: a .h hiányzik az objektumok függőségi sorából. Ellenőrzés: touch lab-sum.h, majd make -n — mindkét objektum fordítását ki kell írnia.
• Tünet (AArch64-útvonal): átugrottad az Az AAPCS64 regiszterszerződés alfejezetet, mert „a hívási konvenciót úgyis ismerem”. Ellenpróba: próbáld meg megmondani, mely regisztereket kell mentenie egy assembly függvénynek, mielőtt a Függvények és az AAPCS64 hívási konvenció fejezethez érsz. Ha nem megy, nem volt átugorható. Cortex-M-útvonalon ugyanezt a kérdést az AAPCS32-re tedd fel.

Rövid összefoglaló

Az előismeret-küszöb az a cselekvésben mérhető C-tudáshalmaz (mutató, struktúra, Makefile, fordítási lánc), amely nélkül a könyv technikai fejezetei nem értelmezhetők. A belépési pont a könyvtérkép azon alfejezete, ahonnan a küszöböt teljesítő olvasó a tudásához igazítva indul: assembly-kezdőnek Miért assembly: amit a C elrejt, ISA-alapokat ismerőnek Az A64 regiszterkészlet áttekintése, AArch64-ismerőnek Thumb-2, a Cortex-M futási modell és a minimal runtime. Az át nem ugorható szerződések útvonalanként különböznek. Az AArch64-útvonalon ez Az AAPCS64 regiszterszerződés, az NVIC itt nem előfeltétel. A Cortex-M-útvonalon az AAPCS32, a memóriatérkép és az NVIC konfiguráció: engedélyezés és prioritás; az AAPCS64 itt csak összehasonlításként hasznos, és nem helyettesíti az M-profile hívási szabályait. Egyik sem a könyv saját konvenciója: az AAPCS64 és az AAPCS32 eljáráshívási szabvány (PCS), vagyis az ABI hívási szabályokat rögzítő része; az NVIC architekturális komponens, amelyhez implementáció- és panelspecifikus beállítások társulnak. Ezeket el kell választani a választott labor saját szerződésétől.

Források és ellenőrzési hiányok

A könyv egészében hivatkozott elsődleges források élő linkjét és aktuális verzióját ennek az átdolgozásnak a részeként ellenőriztük:

• Arm Architecture Reference Manual for A-profile architecture (Arm DDI0487) és Armv7-M Architecture Reference Manual (Arm DDI0403E) — a developer.arm.com/documentation/... linkek élnek (a support.arm.com-ra irányított átirányítás megerősített), de az oldal JavaScript-renderelésű, ezért a pontos fejezetszám/kiadásbetű automatikus lekéréssel nem volt kinyerhető.
• Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64) — github.com/ARM-software/abi-aa, az Az AAPCS64 regiszterszerződés elsődleges forrása. Ellenőrizve: aktuális kiadás 2025Q4 (2026-01-23), Release minőségű (csak az SME-vonatkozású részek Beta).
• Procedure Call Standard for the Arm Architecture (AAPCS32) — github.com/ARM-software/abi-aa, a Cortex-M-útvonal hívási szabályainak elsődleges forrása. Az aktuális kiadás ebben az átdolgozásban nincs ellenőrizve. Az NVIC architekturális leírásának forrása az Armv7-M Architecture Reference Manual (Arm DDI0403E); a megvalósított IRQ-k száma és prioritásbitjei a konkrét mag és panel dokumentációjából ellenőrizendők.
• GNU Binutils, GCC és GDB kézikönyv — három különálló projekt, három különálló dokumentációval: sourceware.org/binutils/docs/ (ellenőrizve: binutils 2.47), gcc.gnu.org/onlinedocs/ (ellenőrizve: legújabb kiadás GCC 16.2), sourceware.org/gdb/current/onlinedocs/gdb.html/ (ellenőrizve, de a „current” egy fejlesztői git-pillanatkép, nem konkrét stabil kiadás).
• A könyv kísérőcsomagja (laborforrások, helyettesítő futtatók, próbák és naplók) — dsk-arm-assembly-tools-1.0.tar.gz, github.com/gellistvan/dsk-arm-assembly-tools, v1.0; tartalmát, ellenőrzőösszegét és futtatását az A-profile és M-profile különbségei alfejezet Források-szakasza írja le. A könyvben tools/… alakban hivatkozott fájlok ennek a csomagnak a fájljai.
• QEMU System és User Mode Emulation dokumentáció — qemu.org/docs/master/. Ellenőrizve: a master ág dokumentációja, nem egy konkrét kiadott verzióé; a ténylegesen telepített QEMU ettől eltérhet.

Ellenőrzési hiányok, amelyek a fenti ellenőrzés után is fennmaradnak: (1) a telepített Ubuntu 24.04 LTS csomagolt GCC/binutils/GDB/QEMU pontos verziószáma ebben a munkafolyamatban nincs lekérdezve; (2) a qemu-system-arm -machine mps2-an385 memóriatérkép mezőnevei a QEMU forráskódjából (hw/arm/mps2.c) ellenőrizendők, ezt a fenti dokumentációs linkek önmagukban nem igazolják; (3) a lab-a000 példa kimenete (60 8), a lab-sum.o elhagyásakor kapott undefined reference hiba és a fejlécmódosítás utáni újrafordítás x86_64 hoston, GCC 13.3.0-val (Ubuntu 24.04) mért; más fordítón és AArch64-en nem mértük, és a sizeof(struct pair) értéke az adott ABI-tól függ, ezért a hallgató laborjában validálandó.

Forrás- és ellenőrzésállapot-jelölések

Az alfejezetek „Források és ellenőrzési hiányok” szakaszai ezekre a jelölésekre hivatkoznak, és csak a saját példájuk feltételeit sorolják fel. A forrásállapot a fenti listára épül (ellenőrzés: 2026-10):

A mérésállapot jelölései eszközverzióhoz és bizonyítékhoz kötöttek: