Hallo, ich habe mir einen gcc mit crosstools-ng gebaut der prinzipiell auch läuft. Allerdings schreibt er, wenn man sich das Ergebnis als Binärdaten ansieht, immer 35 Bytes mit denen ich nichts anfangen kann, an den Anfang. Was danach kommt sieht wie die normale Vektortabelle aus, mit der eigentlich alles starten sollte. Mit dem "offiziellen" gcc von arm selber funktioniert alles. Ich wüsste jetzt trotzdem gerne was da hakt. Das Linkercommandfile habe ich von Atmel genommen. Im ungewünschten Vorspann taucht im Kauderwelsch auch die ASCII Zeichenkette "GNU" auf, falls das jemandem was sagt. Hat jemand eine Idee wie man diesen Vorspann wegbekommt?
Häng mal den Assembler Zwischenschritt (GCC mit -s aufrufen) und das Linker Skript an.
Stefan A. schrieb: > das Ergebnis Welches? In welchem Format? Genau wie erzeugt? Wie sieht dieser Header aus?
Ich habe das Ganze disassembliert: arm compiler:
1 | Disassembly of section .text: |
2 | |
3 | 00000000 <exception_table>: |
4 | 0: 00 04 00 20 e1 00 00 00 a9 01 00 00 a9 01 00 00 ... ............ |
5 | ... |
eigener compiler:
1 | Disassembly of section .text: |
2 | |
3 | 00000024 <exception_table>: |
4 | 24: 00 04 00 20 01 01 00 00 c9 01 00 00 c9 01 00 00 ... ............ |
5 | ... |
Die Option -S zeigt folgenden Anfang:
1 | .cpu cortex-m0plus |
2 | .eabi_attribute 20, 1 |
3 | .eabi_attribute 21, 1 |
4 | .eabi_attribute 23, 3 |
5 | .eabi_attribute 24, 1 |
6 | .eabi_attribute 25, 1 |
7 | .eabi_attribute 26, 1 |
8 | .eabi_attribute 30, 6 |
9 | .eabi_attribute 34, 0 |
10 | .eabi_attribute 18, 4 |
11 | .file "main.c" |
12 | .text |
13 | .Ltext0: |
14 | .cfi_sections .debug_frame |
15 | .global exception_table |
16 | .section .vectors,"a",%progbits |
17 | .align 2 |
18 | .type exception_table, %object |
19 | .size exception_table, 140 |
20 | exception_table: |
21 | .word _estack |
22 | .word Reset_Handler |
23 | .word NMI_Handler |
24 | .word HardFault_Handler |
25 | .word 0 |
26 | .word 0 |
Mit dem eigenen Compiler kommt hier der gleiche Anfang mit Ausnahme der ersten Zeile ".cpu arm7tdmi".
:
Bearbeitet durch User
Der Vollständigkeit halber mein gcc Aufruf:
1 | arm-cortex_m0plus-eabi-gcc -S -nostdlib -mno-pic-data-is-text-relative -marm -mfpu=vfp -mlittle-endian -mthumb -D__SAMD10D13AS__ -ffunction-sections -fdata-sections -Iinclude -D__SAMD10D13AS__ -Wl,"-Tsamd10d13as_flash.ld" -Wall -O0 main.c -Wl,--gc-sections |
Stefan A. schrieb: > eigener compiler: >
1 | Disassembly of section .text: |
2 | > |
3 | > 00000024 <exception_table>: |
4 | > 24: 00 04 00 20 01 01 00 00 c9 01 00 00 c9 01 00 00 ... |
5 | > ............ |
6 | > ... |
7 | > |
Und wo ist hier dein „Kauderwelsch“ oder gar das „GNU“ (47 4E 55)? Kannst du mal ein komplettes Minimalprojekt („Hello world“) zimmern und sowohl Sourcecode als auch erzeugtes ELF-File hier hinlegen? ps: Natürlich bitte mit dem benutzten Makefile.
:
Bearbeitet durch Moderator
Hier der Projektordner. Header und alles sind drin. man beachte die "tastatur.bin" und "tastatur-kaputt.bin" Dateien. Welche aus den elfs der zwei Compiler mittels objcopy generiert wurden.
Stefan A. schrieb: > 00000000 <exception_table>: > 00000024 <exception_table>: Offensichtlich sind da noch andere Daten in ".vectors". Was sagt die Map-Datei dazu? (-Wl,-Map=output.map)
Das neu gebaute ELF-File sieht aber völlig OK aus. Hier das Disassembly:
1 | tastatur.elf: file format elf32-littlearm |
2 | |
3 | |
4 | Disassembly of section .text: |
5 | |
6 | 00000000 <_sfixed>: |
7 | 0: 20000400 .word 0x20000400 |
8 | 4: 0000008d .word 0x0000008d |
9 | 8: 00000155 .word 0x00000155 |
10 | c: 00000155 .word 0x00000155 |
11 | ... |
12 | 2c: 00000155 .word 0x00000155 |
13 | ... |
14 | 38: 00000155 .word 0x00000155 |
15 | 3c: 00000155 .word 0x00000155 |
16 | 40: 00000155 .word 0x00000155 |
17 | 44: 00000155 .word 0x00000155 |
18 | 48: 00000155 .word 0x00000155 |
19 | 4c: 00000155 .word 0x00000155 |
20 | 50: 00000155 .word 0x00000155 |
21 | 54: 00000155 .word 0x00000155 |
22 | 58: 00000155 .word 0x00000155 |
23 | 5c: 00000000 .word 0x00000000 |
24 | 60: 00000155 .word 0x00000155 |
25 | 64: 00000155 .word 0x00000155 |
26 | 68: 00000155 .word 0x00000155 |
27 | 6c: 00000155 .word 0x00000155 |
28 | 70: 00000155 .word 0x00000155 |
29 | 74: 00000155 .word 0x00000155 |
30 | 78: 00000155 .word 0x00000155 |
31 | 7c: 00000155 .word 0x00000155 |
32 | 80: 00000155 .word 0x00000155 |
33 | 84: 00000155 .word 0x00000155 |
34 | 88: 00000155 .word 0x00000155 |
35 | |
36 | 0000008c <Reset_Handler>: |
37 | 8c: b580 push {r7, lr} |
38 | 8e: b082 sub sp, #8 |
39 | 90: af00 add r7, sp, #0 |
40 | 92: 4b26 ldr r3, [pc, #152] ; (12c <Reset_Handler+0xa0>) |
41 | 94: 607b str r3, [r7, #4] |
42 | 96: 4b26 ldr r3, [pc, #152] ; (130 <Reset_Handler+0xa4>) |
43 | ... |
Der ausgenullte Vektor ist die 7 für den USB-Handler, den dein Device nicht hat. Die anderen Vektoren zeigen ordnungsgemäß auf den DummyHandler. Der Fehler muss also irgendwo beim Erzeugen deines Binfiles liegen. Wofür brauchst du das eigentlich überhaupt? Die meisten Tools nehmen doch heutzutage lieber das ELF-File direkt.
Ich flashe das elf file mit openocd. Hier die beiden elf Dateien. @Jörg Wie hast du das Listing bekommen?
:
Bearbeitet durch User
Ich komme der sache näher. Mit dem objdump (habs selber rausgefunden, danke Jörg) kommt:
1 | Disassembly of section .note.gnu.build-id: |
2 | |
3 | 00000000 <.note.gnu.build-id>: |
4 | 0: 00000004 andeq r0, r0, r4 |
5 | 4: 00000014 andeq r0, r0, r4, lsl r0 |
6 | 8: 00000003 andeq r0, r0, r3 |
7 | c: 00554e47 subseq r4, r5, r7, asr #28 |
8 | 10: 4b6f45a1 blmi 1bd169c <STACK_SIZE+0x1bd129c> |
9 | 14: 5a7c6303 bpl 1f18c28 <STACK_SIZE+0x1f18828> |
10 | 18: e4ab12ae strt r1, [fp], #686 ; 0x2ae |
11 | 1c: f8672db8 ; <UNDEFINED> instruction: 0xf8672db8 |
12 | 20: 1ba58415 blne fe96107c <_end+0xde960c7c> |
Es scheint also noch eine Linkersection ".note.gnu.build-id" zu geben.
OK das Problem scheint eine Build ID zu sein und die Option "-Wl,--build-id=none" löst es. Besten Dank an alle Beteiligten.
Trotzdem verwunderlich, dass er das an den Anfang des ELF-Files setzt. Mein Linker macht sowas allerdings nicht, vermutlich älter als deiner. Daher kann ich es hier nicht nachvollziehen.
Stefan A. schrieb: > Es scheint also noch eine Linkersection ".note.gnu.build-id" zu geben. Da fehlt die Zeile "/DISCARD/ : { *(.note.gnu.build-id) }" in der .ld-Datei.
Vielleicht sollte man ja note.* gleich wegwerfen?
Mit der Discard Section in der Linkerdatei gibt es allerdings ein warning.
1 | warning: .note.gnu.build-id section discarded, --build-id ignored. |
Ich werde mal in der Toolchain schauen ob es da eine Option gibt.
Bitte 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.