Hi! Ich brauche einen Tip, wie man die GCC Chain dazu bringt, alle Ausgaben in den .lst Dateien in hex auszugeben, statt der dezimalen Form. Beispiel: 68 0044 28309FE5 str r3, [r2, #-971] 69 0048 CB3302E5 .loc 1 247 0 Für mich wäre #FFFFFC34 besser lesbar als #-971. Bisher verwende ich die Optionen -Wa,-adhlns=$(<:.c=.lst) Habe schon in den binutils Dokus herum gesucht, aber es irgendwie nicht innerhalb der gas -Wa Optionen gefunden. Danke und Gruß Ulrich
Bei den binutils bist Du vermutlich verkehrt, das wird der Compiler so übergeben. Du kannst Dich ja mal durch dessen Switches durchwühlen, ob es da was Passendes gibt; vermutlich eher nicht. Bringt Dir vielleicht ein „arm-...-objdump -dSl file.elf“ ein Format, das näher am Gewünschten liegt? Ich kann's nicht ausprobieren, da ich hier auf diesem Rechner nichts für ARM habe.
Hi! 300144: e3e02a01 mvn r2, #4096 ; 0x1000 300148: e51233c3 ldr r3, [r2, #-963] ; 0x3c3 30014c: e3c33a03 bic r3, r3, #12288 ; 0x3000 300150: e50233c3 str r3, [r2, #-963] ; 0x3c3 Sieht auch nicht wirklich besser aus... Zumal die Ausgabe etwas komisch ist, denn #4096 entspricht ja 0x1000 aber #-963 ist 0xFFFFF3C2, dachte ich... Gruß, Ulrich
Ulrich P. schrieb: > #-963 ist 0xFFFFF3C2 Irgendwie nicht ... die linke Zahl ist ungerade, die andere gerade, das kann nicht sein ... mal nachsehen: -963 ist -0x3c3. Damit hast Du natürlich noch nicht die gewünschte Darstellung im Zweierkomplement (0xfffffc3d), aber da weiß ich Dir sonst keinen Rat.
Ulrich P. schrieb: > ch brauche einen Tip, wie man die GCC Chain dazu bringt, alle Ausgaben > in den .lst Dateien in hex auszugeben, statt der dezimalen Form. Die .lst Dateien werden in meiner Toolchain durch avr-objdump erzeugt. Diese Variante des gnu objdump Programms zeigt die Zahlen hexadezimal an. Einstellen kann man das gem. manpage aber nicht - im Gegensatz zum avr-nm (gnu nm), der kennt die Option --radix Bei mir läuft: $ avr-objdump --version GNU objdump (GNU Binutils) 2.20
Tom M. schrieb: > Die .lst Dateien werden in meiner Toolchain durch avr-objdump erzeugt. Die heißen dort aber ".lss" und sind in Wirklichkeit Disassembler- Listings. Ein Assembler-Listing könntest du bei Bedarf ebenfalls haben (mit den oben erwähnten Optionen). Das -Wa besagt dabei nur, dass der Compiler die nachfolgenden Optionen ohne eigene Begutachtung direkt an den Assembler weiterreichen soll. Ich fürchte aber auch, dass das einfach mal (im obigen Context) der Compiler ist, der das so generiert.
Hc Zimmerer schrieb: > Ulrich P. schrieb: >> #-963 ist 0xFFFFF3C2 > > Irgendwie nicht ... die linke Zahl ist ungerade, die andere gerade, das > kann nicht sein ... mal nachsehen: -963 ist -0x3c3. > > Damit hast Du natürlich noch nicht die gewünschte Darstellung im > Zweierkomplement (0xfffffc3d), aber da weiß ich Dir sonst keinen Rat. Also die Adresse scheint eher ein 0xFFFFFFFF-963 zu sein, denn sonst würde es nicht passen. Ich kenne keinen ARM, der einen Zugriff auf eine ungerade Adresse innerhalb seiner eigenen Register klaglos hin nimmt. @Tom: Es ist in meinem Fall ein arm-none-eabi-objdump mit der Version GNU objdump (GNU Binutils) 2.20.1.20100303 @Jörg: Ich werde es noch mal mit der -Wa,-adhlns=$(<:.c=.lst) Option für den Compile-Lauf versuchen. Zwar löst es nicht das Problem, dass man alle Register Adressen zurück rechnen muss, aber wenigstens ist hier der C-Code und der Assembler Output sauber verschachtelt. Gruß, Ulrich
Ulrich P. schrieb: [ zu str r3, [r2, #-963] ; 0x3c3 ] > Also die Adresse scheint eher ein 0xFFFFFFFF-963 zu sein, denn sonst > würde es nicht passen. Ich kenne keinen ARM, der einen Zugriff auf eine > ungerade Adresse innerhalb seiner eigenen Register klaglos hin nimmt. Das ist ein Offset von -0x3c3 zu r3 und kein Zugriff auf eine ungerade Adresse. Wo das zugreift, hängt vom Register ab.
Ulrich P. schrieb: > Hc Zimmerer schrieb: >> Ulrich P. schrieb: >>> #-963 ist 0xFFFFF3C2 >> >> Irgendwie nicht ... die linke Zahl ist ungerade, die andere gerade, das >> kann nicht sein ... mal nachsehen: -963 ist -0x3c3. >> >> Damit hast Du natürlich noch nicht die gewünschte Darstellung im >> Zweierkomplement (0xfffffc3d), aber da weiß ich Dir sonst keinen Rat. Klingt jetzt wie Haarspalterei, aber der Grund warum die Zahl nicht im ZK dargestellt wird, ist der vorzeichenlose immediate Wert "963", der als Offset verwendet wird. Dieser Offset kann entweder addiert oder subtrahiert werden. Im Opcode selbst wird der Wert gewissermaßen im sign/magnitude Format abgelegt. > Also die Adresse scheint eher ein 0xFFFFFFFF-963 zu sein, denn sonst > würde es nicht passen. Das hat GCC noch nie davon abgehalten das zu generieren }:^) So einen Fall hatte ich erst vor kurzem beim Kunden. > Ich kenne keinen ARM, der einen Zugriff auf eine ungerade Adresse > innerhalb seiner eigenen Register klaglos hin nimmt. Was meinst Du mit "innerhalb seiner eigenen Register"? Sämtliche V6 und v7 Prozessoren (ARM11 und alle Cortex Prozessoren) können unaligned Speicherzugriffe tätigen. Die älteren können das auch, nur erscheint der zurückgelieferte Wert bisweilen etwas merkwürdig. Gruß Marcus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.