Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: mhi 23. 06. 2023, 15:11:30
-
Doporucite mi prosim nekdo nejaky blob na testovani x86 emulatoru (translatoru), aby to umelo v idealni podobe:
- otestovat oddelene 16 a 32bit ruzne ALU operace (tzn. aby slo testovat jen 80(1,2)86 sadu) - na spravny vypocet
- to same na SPRAVNOU praci s flagy
- otestovat ruzne silenosti typu https://www.timdbg.com/posts/useless-x86-trivia/
- otestovat ruzne dalsi instrukce pro pametove operace, opet oddelene 16 (80(1)86) a 32bit (386+) rezim
Jde mi primarne skutecne jen o ALU. Znam treba https://github.com/barotto/test386.asm - takhle presne si to nejak predstavuju, tam bohuzel to ALU +/- chybi.
Doplnujici otazka - potrebuju neco podobneho i na jine sady, konkretne PowerPC a TriCore, 8051, 80166, Z80. Opet primarne zamerene na ALU, nepotrebuju zadne veci jako testy MMU apod.
Po minulych zkusenostech se nezlobte, ale na reakce rikajici mi ze delam blbost nebo ze to mam udelat jinak (pokud to nebude z meho pohledu dobry napad) nebudu vubec reagovat.
-
a co to vykuchat to z existujicich opensource emulatoru? qemu.
-
A nejde vygenerovat brute force metodou vsechny kombinace instrukci a druhu parametru, vcetne ocekavanych side efektu (flagy, vystupy), ktere lze pak overovat na testovanem blackboxu? U IMM muzes vygenerovat nekolik ruznych kombnaci konstant.. nemusi se pokryvat cely 16/32b prostor.
Klidne se z toho da udelat pak jeden exac, pospojovanim dilcich testu, oddelenych s assertions.
-
Dekuji za odpovedi,
ad qemu: tam toho zase tak moc nevidim, nejzajimavejsi je asi toto https://github.com/qemu/qemu/blob/master/tests/tcg/i386/test-i386.c - jenze to neresi uplne muj problem, potrebuju intenzivnejsi testy. Prusvih jsou takove ty ruzne drobnosti typu ze nejaka instrukce nastavuje nebo nenastavuje flagy, obcas se treba parity flag pouziva na neco obskurniho, apod. (ne ze bych tohle zrovna potreboval, to se v mem prekladanem kodu nebude vyskytovat, je to jen priklad).
ad bruteforce: pokud udelam skutecne bruteforce, tak to bude neskutecne dlouhe. Dlouhe to bude i kdyz omezim sady tech imm konstant a vstupu. Po precteni mne napadlo jeste udelat random testsuite, ze by to generovalo pseudonahodne ruzne testovaci sady (zkusime co udela adc nad signed pos a neg 8bit cislem, a pak zkusime jestli jnX bude fungovat vzdy stejne (a preskocime podminene dalsi testovaci pseudorandom kod).
Jinak tohle je reset kod pocitace TNS HC16:
seg000:E104 reset_routine proc near
seg000:E104 sub ax, [bx+si]
seg000:E106
seg000:E106 loc_FE106: ; CODE XREF: int9_irq1_kbd+100
seg000:E106 cli
seg000:E107 cld
seg000:E108 xor ax, ax
seg000:E10A sahf
seg000:E10B jb short err01
seg000:E10D jz short err01
seg000:E10F jp short err01
seg000:E111 js short err01
seg000:E113 daa
seg000:E114 or al, al
seg000:E116 jnz short err01
seg000:E118 not ah
seg000:E11A sahf
seg000:E11B jnb short err01
seg000:E11D jnz short err01
seg000:E11F jnp short err01
seg000:E121 jns short err01
seg000:E123 daa
seg000:E124 cmp al, 66h ; 'f'
seg000:E126 jnz short err01
seg000:E128 mov ax, 5555h
seg000:E12B cmp al, ah
seg000:E12D jnz short err01
seg000:E12F shl al, 1
seg000:E131 or al, ah
seg000:E133 cmp al, 0FFh
seg000:E135 jnz short err01
seg000:E137 mov ah, al
seg000:E139
seg000:E139 loc_FE139: ; CODE XREF: reset_routine+4Fj
seg000:E139 mov ds, ax
seg000:E13B mov bx, ds
seg000:E13D mov es, bx
seg000:E13F mov cx, es
seg000:E141 mov ss, cx
seg000:E143 mov dx, ss
seg000:E145 mov sp, dx
seg000:E147 mov bp, sp
seg000:E149 mov si, bp
seg000:E14B mov di, si
seg000:E14D sub ax, di
seg000:E14F jnz short err01
seg000:E151 shl cx, 1
seg000:E153 jnb short loc_FE139
seg000:E155 jmp short loc_FE159
seg000:E155 ; ---------------------------------------------------------------------------
seg000:E157 db 90h ; É
seg000:E158 ; ---------------------------------------------------------------------------
seg000:E158
seg000:E158 err01: ; CODE XREF: reset_routine+7j
seg000:E158 ; reset_routine+9j ...
seg000:E158 hlt
-
On ten bruteforce neni zas tak velky, mnozina kombinaci operandu / adresnich rezimu a typu instrukce bude konecna. Nejvetsi objem do toho vnasi hodnoty nad kteryma operujes a tam staci vygenerovat nejaky random bordel (treba hash funkci) plus par zajimavych hodnot (-1,0,1) a pak to tim prohnat. Automaticky wrapper by pak operand pred-vlozil do spravneho registru nebo na spravnou adresu a otestoval vystup.
Pripadne si proti svemu VM pust tohle - https://github.com/xoreaxeaxeax/sandsifter - a zjisti ti to veskere podivne chovani :)
-
Teoreticky ty instrukce nemusíš ani emulovat.
Existoval takový projekt, WinREPL, který ale autor archivoval a už je jen tady (https://github.com/zerosum0x0-archive/archive) - a ten ty instrukce JIT zokpiloval a pustil, takže člověk dostal přesný výsledek.
Na druhou stranu 16-bit assembler - to je něco tak historického, že tím se dnes moc lidí teda nezabývá.
-
Je vidět, že jdete dost do hloubky. Snad by vám mohl pomoci třeba dr. Pavel Píša (https://cmp.felk.cvut.cz/~pisa/) & kol. Dělají mj. simulaci procesorů, co vím tak MIPS a RISC-V, ale obecně učí architektury počítačů, takže i X86. Nějaká testovací sada existovat musí, je ale otázkou zda to nemají výrobci specificky pro daný čip a ještě k tomu pod NDA.
Ono je to vůbec problematické. Pamatuji dobu, kdy se CPU skládaly z TTL obvodů, tam měly testy jakýsi smysl, ale obvykle chyba v CPU způsobila nefunkčnost už v bootloaderu, takže nešlo test dostat do RAM a tudíž ani spustit. V simulaci to bude podobné. Pokud na tom spustíte jakýkoli komplexnější program a funguje to podle předpokladu, dobře. Pokud to funguje divně nebo vůbec, pak se chyba dost blbě hledá.
-
Ono je to vůbec problematické. Pamatuji dobu, kdy se CPU skládaly z TTL obvodů, tam měly testy jakýsi smysl, ale obvykle chyba v CPU způsobila nefunkčnost už v bootloaderu, takže nešlo test dostat do RAM a tudíž ani spustit. V simulaci to bude podobné. Pokud na tom spustíte jakýkoli komplexnější program a funguje to podle předpokladu, dobře. Pokud to funguje divně nebo vůbec, pak se chyba dost blbě hledá.
Tohle je prave falesny pocit jistoty. Pokud chcete mit solidni implementaci, tak ji musite byt schopen otestovat - a chybu odhalit jinak - na nizke urovni, nez tim, ze vam sehlava javascript v prohlizeci. V podstate je to stejny pristup jako u testbenche pro HDL kod - kdy jeste mate sanci vychytat nejake implementacni bugy, nez za hodne milionu nechate vyrobit masku, pripadne spustite vyrobu produktu.
Ostatne testovaci vektory se pouzivaji i na hotovych cipech, kvuli urceni, zda jsou vubec funkcni.
Jako chapu autorovu potrebu mit testovaci sadu, a z duvodu dvojite chyby by takovy test mel napsat nekdo jinej nez on. A az budou mit oba hotovo, tak to muzou poustet behem vyvoj dokola a dokola.. a odhalovat pripadne regrese v kodu.
Imho INTEL takove testovaci/verifikacni sady ma.. ale nebudou verejne dostupne.
Kluci z Centaur Technology resili podobny problem:
https://www.cl.cam.ac.uk/~jrh13/spisa19/paper_08.pdf
-
Ale hlavně X86 instrukční sada má hodně dokumentace, a pokud někoho zajímá jen ALU, tak to není až tak moc instrukcí. Takže prostě jednu za druhou implementovat, udělat tester té implementace a porovnat to s nativním kódem.
Jinak možná bych se podíval i na valgrind, ten taky umí emulovat kde co :)
-
Kdyby z toho čouhal balík peněz, tak bych se tomu docela rád věnoval.
-
Kdyby z toho čouhal balík peněz, tak bych se tomu docela rád věnoval.
z toho couha leda hafo roboty :-)
-
Nojo, ale není lepší, když z tohou čouhají i prašule :-D ?
Já rád prašule... :o
-
Nojo, ale není lepší, když z tohou čouhají i prašule :-D ?
Já rád prašule... :o
to vsichni radi :-)
-
No já nejsem náročnej, stačil by mi plat programátora v nějaké neziskovce, třeba v Thunderbirdu má programátor 20 000 dolarů. S tím bych neměl problém. Pak bych klidně dělal i nějaký free melouch :-D
-
Jako chapu autorovu potrebu mit testovaci sadu, a z duvodu dvojite chyby by takovy test mel napsat nekdo jinej nez on. A az budou mit oba hotovo, tak to muzou poustet behem vyvoj dokola a dokola.. a odhalovat pripadne regrese v kodu.
Nakonec to asi budu muset naprogramovat sam. Zvazuju jestli mam vubec resit PF. A jestli ma smysl AF. V target kodu se myslim ani jedno nepouziva, ale muzu se samozrejme plest. PF vyresit muzu celkem snadno tim, ze si nekam po ukonceni translace basic bloku NEBO informaci ze potrebuju plne flagy ulozim vysledek a pak pouziju lookup table, to same na ten AF, jen to jsou uplne zbytecne cykly navic.
K otestovani jsou:
- vypocty EA
- prehozy mezi registry: pushpop, segmentove
- ALU operace rozdelen i na 8 / 16 / 32 bitu a ruzne formaty zapisu X testy ruznych flagu x ruzne vstupy (rozdily horniho bitu, preteceni, apod.).
Prvni reseni bude asi udelat nejakou tabulku, ktera bude obsahovat tyhle ruzne vektory a pak nejspis pres random nagenerovat sadu testu, kde si treba na stacku budu naxorovavat vysledky, a srovnam realne CPU vs. translaci. Sice to neni idelani, ale odhali to asi spoustu chyb. Nektere vyzivnejsi sady si ulozim jako testvektory.
Jsem zvedav, jestli najdu i nejakou chybu v nejakych emulatorech a jestli to treba dobehne dobre na Win/ARM :).
-
Jeste poznamka: emulace celeho cpu vs translace userpace kodu se bude lisit.. protoze to prvni je dost kontextove zavisle - potrebuje i znat aktualni rezim a nastaveni - CR0/CR4, nez tomu hodis nejaky byte-stream jako instrukci, zatimco kod z moderni userspace aplikace bude vzdy jen podmnozina.
-
Ano, v jinem projektu jsem to resil tak, ze u kazdeho basic blocku byl krome startadresy ulozeny i rezim. Tady to ale nebude potreba, default je 32bit a vse dal uz urci addr/op prefixy.