Jeg reverserer statisk noe 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 er jeg i tvil om at 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?
Rediger : 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 den andre instruksjonen som hentes mens den første blir dekodet , utførelse av grenforsinkelsessporet burde faktisk starte. Avdelingens instruksjon er imidlertid avhengig av at det samme registeret blir endret av instruksjonen i grenforsinkelsessporet, så hva vil skje? Vil greninstruksjonen evaluere tilstanden ved hjelp av det gamle registeret va lue, eller den nye oppdatert av lb?
Takk
Kommentarer
- Du kan dra nytte av å lese MIPS-serien av Raymond Chen her: lenke Det første svaret er nei (og se lenken for detaljer). Jeg kan ' ikke svare på det andre.
Svar
Instruksjonen i grenforsinkelsessporet evalueres etter gren (eller hopp) instruksjonen. Utførelsen av instruksjonen i grenforsinkelsessporet påvirker ikke evalueringen av forgreningstilstanden.
Jeg har observert at grenforsinkelsessporet brukes til noen få ting:
- Siste instruksjon av grunnleggende blokk som fører til greninstruksjon
- Grenprøve vil ikke være avhengig av utdata fra beregningen av grenforsinkelses sporinstruksjon
- Vanligvis sett med ubetingede hopp / grener som
b,jal
- Den første instruksjonen om fall gjennom blokken .
- Ingen bivirkninger bør være til stede hvis filialen tas.
- Analyse vil vise at det ikke er behov for registrer som påvirkes i tilfelle filialen tas
- Den første instruksjonen for blokk hvis grenen tas
- Hvis det er flere baner til grenmålet, vil denne instruksjonen trolig bli sett flere ganger med de forskjellige grenene
- Belastningen av en betinget verdi, ofte for returverdier
Denne artikkelen går i detalj om grenforsinkelsesspor.
Som bemerket av Igor, holder den «sannsynlige» versjonen av greninstruksjonen kun effekten av instruksjonen i grenforsinkelsessporet hvis instruksjonen faktisk blir tatt.
Svar
- Det er variasjoner av betingede grener kalt «gren [på tilstand] sannsynlig», f.eks.
-
bgezl– Forgrening større enn eller lik null sannsynlig -
beqlLike sannsynlig
-
Disse instruksjonene har et forsinkelsesspor, men instruksjonen i forsinkelsessporet utføres bare hvis grenen er tatt. Hvis grenen ikke blir tatt, blir instruksjonen i forsinkelsessporet ikke utført ( nullisert ) .
NB: disse instruksjonene er fjernet i versjon 6 av MIPS Architecture. Det la også til kompakte varianter av grener som ikke har forsinkelsesspor
Når det gjelder kodebiten din, mistenker jeg sterkt at grenen bruker gamle registerverdien, men du kan sannsynligvis bekrefte den bare ved å kjøre den på en faktisk prosessor.