Memorymonitor & .map

Harvey · #1

Hai,

bekommt man damit irgendwie raus, in welcher Funktion ein TAP den Topf ins Koma schickt?

Irgendwie müsste man dazu erst mal wissen, an welche Adresse das TAP geladen wurde, nur genau das weiss ich nicht wie herausfinden.

Seid bedankt.

[laut denkend]
$ra=82852e0c und epc=82852e34 wundert mich. So kurze Funtionen mit max. 10 Maschineninstruktionen habe ich garnicht drin. Aber wie umständlich Compiler und Linker die TAPs übersetzten müssen nur damit diese Adressenunabhgängig arbeiten könnte das mit dem Debugging eh schwierig werden

[/laut denkend]

t3xi · #2

Ich wusste gar nicht dass es einen Memorymonitor gibt. Auch haben wollen.

FireBird · #3

Bevor ich Dich missverstehe und eine 20 seitige Abhandlung umsonst schreibe: Du möchtest im Prinzip eine absolute Adresse in eine relative Adresse umrechnen?

Harvey · #4

Ich vermute, wir meinen das gleiche, wenn ich dich nicht missverstehe. Ehr die relative in die ursprünglich absolute (welche in der .map steht), aber das schaffe ich dann auch

Wenn der Topf abkachelt ist er ja meistens so nett, per serieller Schnittstelle den Inhalt der Register mehr oder weniger vollständig auszuwerfen.

@t3xi: das hat Topfield, so glaube ich, Memorymonitor genannt (diesmal hat dieses Windowsinterne Hyperterminal den Namen nicht ausgespuckt). Viel ist damit nicht anzufangen, wenn der Prozessor in irgend einer Schleife hängt.

Harvey · #5

Es eilt nicht mehr, neugierig wäre ich trotzdem.

FireBird · #6

Die Einsprungadresse für die TAP-Routinen holt er sich aus einer Tabelle und das macht er mitten in Deinem Code. Aus den CPU-Regs kann man nichts schließen.

Aber man kann die Ladeadresse via TAP-Table herausfinden und den EPC in eine relative Adresse im TAP-Disassembly umrechnen. Dann ist es aber immer noch eine Mordssucherei, die Stelle in den C-Source zu übersetzen.

Harvey · #7

Sagen wie mal so. Ich bakam EPC=82852e34. Da das jenseits der Firmware liegt muss das im TAP selber gewesen sein. Wenn ich jetzt wüsste, wohin das TAP geladen worden ist, könnte ich aus der Differenz die Stelle in der .map abschätzen (ich kompiliere selbst).

Indirekt kann ich aber mit deiner Info was anfangen. Jetzt fehlt mir nur noch der Offset bezogen auf TAP-Table[TAP-Nr]. Und ob noch irgendwelche Segmente abgezogen werden müssen (z.B.

Code: Alles auswählen

._tap_init_data
                0x0000000000000000      0x600
......
                0x0000000000000200                __startPoint

.text           0x0000000000000600    0x2e07c
 *(.text)
 .text          0x0000000000000600     0x3204 myTAP.o

FireBird · #8

Grundsätzlich kannst Du im TAP die Variable _tap_startAddr verwenden. Aber ein paar Backgroundinfos: Jeder der 16 Records der TAP-Table hat folgende Einträge:

dword FW $gp
dword TAP $gp
dword ?
dword TAP Load Address
dword Jump Table
dword TAP Load Address
dword Actual Directory
byte Terminate Flag
byte unused [3]???

Actual Directory zeigt auf eine Kopie des .-Verzeichnisses. Einzige brauchbare Info ist die Clusternummer.

Terminate Flag wird von TAP_Exit auf 1 gesetzt und dann wir das TAP beim nächsten Idle Loop aus dem Speicher geschmissen

TAP_Load_Address
+ 0x0000 = File header TFAPMIPS
+ 0x0020 = TAP ID
+ 0x0040 = Program name
+ 0x0080 = Author
+ 0x00c0 = Description
+ 0x0140 = Compile Date
+ 0x0200 = Jump Table
+ 0x0600 = Code Segment

Die Jump-Table besteht aus 256 dwords und ein paar interessante Indices sind:

01: TAP_Main
07: TAP_EventHandler

Ab Index 0x0a beginnen die TAP_*-Funktionen (0x0a zeigt z.B. auf TAP_SystemProc).

Harvey · #9

Genial. Vielen Dank.