Jeg reverserer statisk programvare som er samlet for en Atheros AR7161 ved hjelp av radare2. Denne prosessoren implementerer MIPS, og jeg husker at MIPS har en grenforsinkelsesspor. Dette merkes faktisk i demonteringen fordi jeg kan se instruksjoner som logisk skal utføres før grener blir plassert rett etter dem.
Imidlertid, mens jeg analyserte noe kode, kom jeg over en beqz-instruksjon som antar at instruksjonen etter at den skal utføres først gir ikke mening i sammenheng med programmet. Jeg må innrømme at analysen min kan være feil, noe som ikke er usannsynlig; Imidlertid har jeg noen tvil som jeg også vil fjerne:
-
Gjør alle gren- / hoppinstruksjoner alltid bruk grenforsinkelsessporet slik at instruksjonen rett etter skal logisk utføres først ? Hvis ikke, i hvilke tilfeller ville det ikke vært?
-
Er det noen måte å få radare2 til å vise den logiske kjøringsrekkefølgen i stedet for den som er kodet i binærfilen?
Edit : konkret, jeg har å gjøre med følgende sekvens:
beqz v0, <some address>lb v0, 0x40 (sp) Jeg har et veldig diffust bilde i hodet på meg om at denne instruksjonen går ut i rørledningen. Jeg kan se for meg at den andre instruksjonen blir hentet mens den første blir dekodet; Derfor skal utførelsen av grenforsinkelsessporet faktisk starte. Greninstruksjonen er imidlertid avhengig av at samme register blir endret av instruksjonen i grenforsinkelsessporet, så hva vil skje? Vil filialinstruksjonen evaluere tilstanden ved hjelp av den gamle registerverdien, eller den nye oppdatert av lb?
Takk