Hi, hat von euch jemand Ahnung von radare2 und ob ich damit eine hex einigermaßen lesbar machen kann? Letzendlich ist es mein eigener Code, doch mir ist die Versionierung abgeraucht und die aktuelle Implementierung läuft an einer Stelle noch nicht so rund, wie sie es einmal war (Atmega88 PWM über timer1). Ja vermutlich werden nun wieder einige aufschreien und sagen, das Projekt kennen wir doch bereits, aber ich sehe den Fehler einfach nicht. Grüße David PS: Ich kann kein ASM
Gast
#5806897
D a v i d K. schrieb: > PS: Ich kann kein ASM Dann hast du sowieso schon verloren. Der einfachste Weg wäre es, sich den Assemblercode mit gcc-objdump ausgeben zu lassen (vllt sind ja Symbole in der elf) und dann die entsprechende Funktion zu untersuchen, die paar Assemblerbefehle kannst du ja auf google nachschauen.
Gast
#5807815
Stell mal das Hex und deinen C(?) Code hier ein.
D a v i d K. schrieb: > Ja vermutlich werden nun wieder einige aufschreien und sagen, das > Projekt kennen wir doch bereits, aber ich sehe den Fehler einfach nicht. Stell mal den Code rein, da können die komischten Dinge Probleme verursachen. eventuell fällt ja jemandem hier was auf. gerade bei Timern/PWM kann es Probleme mit aktualisierung der Register geben, wenn du nicht alles beachtest. z.b. hatte ich auf einem tiny zwischen CTC und PWM umgeschaltet (was das OCR register zwischen buffered/direct access umschaltet), was bei falscher Reihenfolge der Initialisierungen dazu führte dass der Code nach 1 1/2 Durchläufen hängeblieb, aber nur wenn OCR zu einer bestimmten Zeit unter 26 war.
Gast
#5808919
Du kannst mit avr-objcopy das hex file in eine elf file konvertieren und dieses dann in radare2 öffnen. radare2 wird dir den Assemblercode anzeigen, aber dazu z.B. die Sprungmarken/-Pfeile und es kann nach versuchen Funktionen zu erkennen (wird angesprungen und endet mit ret). Namen von den Symbolen bekommst du so natürlich nicht, die sind beim Übergang elf->hex weggefallen.
Gast
#5809019
Alternativ kann man sich mit avr-objdump auch schon das disassemblierte Programm anschauen und braucht nicht mal radare dafür (obwohl es komfortabler ist). avr-objdump.exe -j .sec1 -d -m avr5 input.hex > output.dasm Den Namen der Section (.sec1) kann man bei Bedarf mit avr-objdump.exe -h input.hex ermitteln (war bei mir aber immer .sec1, warum auch immer).
Git sei dank, habe ich mir die "noch lauffähige" version querry-picken können :) Trotzdem würde den wissenhungrigen Part in mir interessieren, wie ich nach dem compilieren bestimmte Werte im Hex wiederfinde. Kann ich gewisse Dinge beim programmieren ändern, damit es leichter wird? (Vermutlich compilerflag komprimiere=0?)
D a v i d K. schrieb: > Kann ich gewisse Dinge beim programmieren ändern, damit es leichter > wird? Ja, Optimierung abschalten. Dann entspricht das Assemblat eher Deinem Programm.
Ich würde mir auch mal Ghidra angucken. Das ist ein von der NSA entwickeltes Reverse engineering Tool vergleichbar mit IDA Pro. Das kommt auch mit decompiler für zig Prozessorarchitekturen und ist damit deutlich einfacher verwendbar für Leute, die nicht so ASM affin sind. Klar ist reverse engineering immer noch Arbeit, aber für mich klar einfacher, wenn ich mir nicht alle ASM compare und Jump Befehle merken muss. Radare hat zwar auch nen decompiler, aber ich bin insgesamt nie mit Radare warm geworden.
Gast
#5818699
Rufus Τ. F. schrieb: > D a v i d K. schrieb: >> Kann ich gewisse Dinge beim programmieren ändern, damit es leichter >> wird? > > Ja, Optimierung abschalten. Dann entspricht das Assemblat eher Deinem > Programm. Würde ich nicht machen. Optimiertes Assemblat ist viel lesbarer als unoptimiertes. Das gilt meistens auch für C vs. Assembler: Wer sich schon mal den glibc C-Code angeschaut hat und mit dem Asm verglichen hat, wird den Asm bevorzugen (mit Optimierungen)
Ralf C. schrieb: > Würde ich nicht machen. Optimiertes Assemblat ist viel lesbarer als > unoptimiertes. Wenn man das Assemblat ohne Bezug zum C-Quellcode lesen will, vielleicht. Möchte man aber die Zusammenhänge erkennen, eher nicht.