gcc für cortex-m0 schreibt daten vor die Vektortabelle

Stefan A. (king-crash) 19.10.2017 10:17 #5180405

Lesenswert?

•

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?

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Daniel Gast 19.10.2017 10:25 #5180416

Lesenswert?

•

▲
▼

Häng mal den Assembler Zwischenschritt (GCC mit -s aufrufen) und das 
Linker Skript an.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Daniel Gast 19.10.2017 10:26 #5180420

Lesenswert?

•

▲
▼

natürlich -S
nicht -s

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Clemens L. (c_l) 19.10.2017 10:26 #5180421

Lesenswert?

•

▲
▼

Stefan A. schrieb:
> das Ergebnis

Welches? In welchem Format? Genau wie erzeugt? Wie sieht dieser Header 
aus?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 10:47 #5180442

Lesenswert?

•

▲
▼

Ich habe das Ganze disassembliert:

arm compiler:

Disassembly of section .text:
00000000 <exception_table>:
   0:  00 04 00 20 e1 00 00 00 a9 01 00 00 a9 01 00 00     ... ............


eigener compiler:

Disassembly of section .text:
00000024 <exception_table>:
  24:  00 04 00 20 01 01 00 00 c9 01 00 00 c9 01 00 00     ... ............


Die Option -S zeigt folgenden Anfang:

  .cpu cortex-m0plus
  .eabi_attribute 20, 1
  .eabi_attribute 21, 1
  .eabi_attribute 23, 3
  .eabi_attribute 24, 1
  .eabi_attribute 25, 1
  .eabi_attribute 26, 1
  .eabi_attribute 30, 6
  .eabi_attribute 34, 0
  .eabi_attribute 18, 4
  .file  "main.c"
.Ltext0:
  .cfi_sections  .debug_frame
  .global  exception_table
  .section  .vectors,"a",%progbits
  .align  2
  .type  exception_table, %object
  .size  exception_table, 140
exception_table:
  .word  _estack
  .word  Reset_Handler
  .word  NMI_Handler
  .word  HardFault_Handler
  .word  0
  .word  0

Mit dem eigenen Compiler kommt hier der gleiche Anfang mit Ausnahme der 
ersten Zeile ".cpu arm7tdmi".

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 11:03 #5180457

Lesenswert?

•

▲
▼

Der Vollständigkeit halber mein gcc Aufruf:

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jörg W. (dl8dtl) Moderator 19.10.2017 11:23 #5180475

Lesenswert?

•

▲
▼

Stefan A. schrieb:

> eigener compiler:
>

Disassembly of section .text:
> 00000024 <exception_table>:
> ............


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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 11:36 #5180493

Lesenswert?

•

▲
▼

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.

Angehängte Dateien:

src.tar.bz2 (263 KB)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Clemens L. (c_l) 19.10.2017 11:41 #5180498

Lesenswert?

•

▲
▼

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)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Clemens L. (c_l) 19.10.2017 11:42 #5180500

Lesenswert?

•

▲
▼

Stefan A. schrieb:
> Hier der Projektordner.

Das ist aber dein Compiler nicht drin.  ;-)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jörg W. (dl8dtl) Moderator 19.10.2017 11:43 #5180502

Lesenswert?

•

▲
▼

Das neu gebaute ELF-File sieht aber völlig OK aus.  Hier das
Disassembly:

tastatur.elf:     file format elf32-littlearm
Disassembly of section .text:
00000000 <_sfixed>:
   4:   0000008d        .word   0x0000008d
        ...
        ...
0000008c <Reset_Handler>:
  8c:   b580            push    {r7, lr}
  8e:   b082            sub     sp, #8
  90:   af00            add     r7, sp, #0
  92:   4b26            ldr     r3, [pc, #152]  ; (12c <Reset_Handler+0xa0>)
  94:   607b            str     r3, [r7, #4]
  96:   4b26            ldr     r3, [pc, #152]  ; (130 <Reset_Handler+0xa4>)


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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 11:51 #5180513

Lesenswert?

•

▲
▼

Ich flashe das elf file mit openocd.
Hier die beiden elf Dateien.

@Jörg Wie hast du das Listing bekommen?

Angehängte Dateien:

elf.tar.bz2 (138 KB)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 12:18 #5180546

Lesenswert?

•

▲
▼

Ich komme der sache näher.
Mit dem objdump (habs selber rausgefunden, danke Jörg) kommt:

Disassembly of section .note.gnu.build-id:
00000000 <.note.gnu.build-id>:
   0:  00000004   andeq  r0, r0, r4
   4:  00000014   andeq  r0, r0, r4, lsl r0
   8:  00000003   andeq  r0, r0, r3
   c:  00554e47   subseq  r4, r5, r7, asr #28
  10:  4b6f45a1   blmi  1bd169c <STACK_SIZE+0x1bd129c>
  14:  5a7c6303   bpl  1f18c28 <STACK_SIZE+0x1f18828>
  18:  e4ab12ae   strt  r1, [fp], #686  ; 0x2ae
  1c:  f8672db8       ; <UNDEFINED> instruction: 0xf8672db8
  20:  1ba58415   blne  fe96107c <_end+0xde960c7c>


Es scheint also noch eine Linkersection ".note.gnu.build-id" zu geben.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 12:33 #5180555

Lesenswert?

•

▲
▼

OK das Problem scheint eine Build ID zu sein und die Option 
"-Wl,--build-id=none" löst es.

Besten Dank an alle Beteiligten.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jörg W. (dl8dtl) Moderator 19.10.2017 12:50 #5180568

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Clemens L. (c_l) 19.10.2017 12:58 #5180578

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jörg W. (dl8dtl) Moderator 19.10.2017 13:01 #5180581

Lesenswert?

•

▲
▼

Vielleicht sollte man ja note.* gleich wegwerfen?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan A. (king-crash) 19.10.2017 13:08 #5180593

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

gcc für cortex-m0 schreibt daten vor die Vektortabelle

Antwort schreiben