Hi, Habe Heute einfach mal ein Assembler Projekt von mir mit IDA disassembliert, und festgestellt das nicht alles gleich ist wie ich es im Asm-Sourcecode geschrieben habe. Zum Beispiel wird das Register R19 benutzt obwohl ich es im Sourcecode nirgendwo benutzt habe. Ein Paar Funktionen erkenne ich wieder, und ein paar habe ich noch nie gesehen. Wie ist das möglich, warum werden andere Register benutzt als im Sourcecode angegeben? Danke
Gast
#1399165
Automatische Optimierung.
Gast
#1399168
Beispiel?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
also das hier zum Beispiel, im Sourcecode steht davon nichts. p.s. wo stellt man denn die Optimierung ab?
Der Disassembler hat keine Ahnung, was im ROM Daten sind und was Code ist. Disassemblierte Daten sehen öfter etwas schräg aus. Erkennt man besser, wenn man zu den Befehlen auch die Bytes sieht.
Ich habe mal davon gehört das man das im Disassembler simulieren kann und so rausfinden kann was Daten und was Code ist. Habe ich das so richtig verstanden und ist das mit IDA möglich?
Christian D. schrieb: > also das hier zum Beispiel, im Sourcecode steht davon nichts. Kann ja jeder behaupten. Wir können es nicht nachprüfen. > p.s. wo stellt man denn die Optimierung ab? gibbet nich. Ein Assembler muß genau das übersetzen, was Du hingeschrieben hast. Peter
>> also das hier zum Beispiel, im Sourcecode steht davon nichts. >Kann ja jeder behaupten. >Wir können es nicht nachprüfen. Stimmt wirklich! glaub mir. ich benutze nur r16, r17 und r18. Es können also nur die Sachen aus dem Datensegment sein. Kann mir jemand sagen wie ich das simulieren kann das ich herausfinde was Code und Daten ist?
Gast
#1399232
In der disassemblierten Liste solltest Du die Darstellung der erzeugten Codebytes mit anschalten, nicht nur der Adressen. Dann wird man vermutlich sehen, daß es sich bei den vermeintlichen Programmschritten nach "rcall sub_2A8" um irgendwelche Konstanten oder Tabellen etc. handelt. Evtl. sind es Zahlenkonstanten für die Subraktion. Noch einfacher ist es, wenn man den Assembler einen "Listfile" erzeugen lässt, dann sieht man alles genau und braucht keine separaten Disassembler. Diese werden nur bei Analyse von Fremdcode eingesetzt.
Christian D. schrieb: > Kann mir jemand sagen wie > ich das simulieren kann das ich herausfinde was Code und Daten ist? Geht nicht, dazu bräuchte der Disassembler Intelligenz. Es gibt Disassembler, wo man manuell Codesequenzen ausschließen kann. Manche Disassembler können auch alle Sprungmarken verfolgen, bis zum nächsten unbedingten Sprung oder return. Das geht, solange man keine Funktionspointer benutzt. Aber wenn Du eh den Quellcode hast, dann brauchst Du doch nicht disassemblieren, nimm einfach das Assemblerlisting. Peter
Christian D. schrieb: ROM:01E9 sbci r20, 0x54 ; 'T' > ROM:01EA sbci r20, 0x36 ; '6' > ROM:01EB sbci r19, 0x44 ; 'D' > ROM:01EC sbci r19, 0x50 ; 'P' > ROM:01ED sbci r19, 0x41 ; 'A' Siehst Du, dass die Operanden Text ergeben? Und so wird es auch mit dem Operator sein. Irgendwo in Deinem Programm steht der String ...".T.6.D.P.A."... (Die Punkte stehen für weitere Zeichen, da Dein Disassembler-Listing leider die Code-Bytes weglässt). Das kommt einfach heraus, wenn man Strings disassembliert. Woher soll der Disassembler auch wissen, dass das Programm dort selbst nicht vorbeikommt, sondern diesen Teil als Daten verwendet?
du kannst im IDA die analyze abeim laden bschalten, dann wird IDA erstmal z.b. die strings auflisten. Blocks die wie code aussehen markieren und "C" drücken, dann bekommst du auch da code disassembliert wo code drin ist - im string fenster die addressen vergleichen damit du keine string disassemblierst. IDA ist schon super, allerdings falls du wirklich die lizenz gekauft hast solltest du es wissen :)
>> ROM:01E9 sbci r20, 0x54 ; 'T' >> ROM:01EA sbci r20, 0x36 ; '6' >> ROM:01EB sbci r19, 0x44 ; 'D' >> ROM:01EC sbci r19, 0x50 ; 'P' >> ROM:01ED sbci r19, 0x41 ; 'A' Ich werfe mal folgende Version ins Rennen: Struktur des sbci-Befehls: 0100 KKKK dddd KKKK Befehle analysiert: ROM:01E9 sbci r20, 0x54 ; 'T' 0100 0101 0100 0100 = 0x4544 = 'E','D' ROM:01EA sbci r20, 0x36 ; '6' 0100 0011 0100 0110 = 0x4346 = 'C','F' ROM:01EB sbci r19, 0x44 ; 'D' 0100 0100 0011 0100 = 0x4434 = 'D','.' ROM:01EC sbci r19, 0x50 ; 'P' 0100 0101 0011 0000 = 0x4530 = 'E','0' ROM:01ED sbci r19, 0x41 ; 'A' 0100 0100 0011 0001 = 0x4431 = 'D','1' ASCII-Folge also 'EDCFD.E0D1' Reinhard
> Ich werfe mal folgende Version ins Rennen:
Stimmt. Die Nibbles sind verwürfelt, das habe ich nicht bedacht.
Reinhard Richter schrieb: > ASCII-Folge also 'EDCFD.E0D1' Ist AVR im ROM big endian?
Es ist auch die Frage, wie herum der Disassembler die Bytes anzeigt. Ein AVR-Assembler-Listing zeigt z.B. die Bytes anders herum an als eines von gas (dem Gnu Assembler) und vom avr-objdump-Disassembler.