arm-none-eabi-objcopy: HEX ist nur wenige Bytes groß

[JensH (Gast)]

Hallo,
ich bin dabei die STM32 Toolchain unter Linux neu aufzusetzen. Eclipse. 
CodeSourcery Lite mit GCC 4.8.1.
Ein Projekt das ich vor einem Jahr mal gemacht habe lässt sich auch 
kompilieren. Die Objekt-Files sind entsprechend groß und die ELF Datei 
hat 500kb.

Es wird aber beim Speicherverbrauch nur wenige Bytes angezeigt. Denn 
nach dem Linken zum elf wird ein:

arm-none-eabi-objcopy -O ihex "projekt.elf" "projekt.hex"

ausgeführt, und das Hex ist auch nur wenige Bytes.

Was könnte der Grund sein? Weiss nicht sorecht, wo ich suchen soll.

Wenn ich ein neues Demo-Projekt anlege und schreibe dort ein int 
test[1000] rein und geb das über printf aus, dann ist auch dort der RAM 
Verbrauch nur wenige Bytes.

Grüße.

[Dr. Sommer (Gast)]

Mach mal ein "arm-none-eabi-readelf -S projekt.elf" um die Größen von 
.text und .data anzuzeigen. Wenn die schon verdächtig klein sind, hat 
die elf->hex konvertierung damit nichts zu tun. Vielleicht wird bei dir 
was unabsichtlich wegoptimiert, wie zB der ISR-Vector und die ISR's; in 
diesem Fall mal mit __attribute__((used)) markieren. Disassembly 
angucken hilft auch oft.

[JensH (Gast)]

Das mach ich gleich.
Aber eines hab ich rausgefunden, dass mit arm-none-eabi-objdump -d nur 
sehr wenig angezeigt wird, mit arm-none-eabi-objdump -D aber alles.
Es scheint so, als ob fast alles in Speicherbereichen steht, die nicht 
gültig sind. Vielleicht ist beim Linkerfile was daneben gegangen.

[JensH (Gast)]

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .init             PROGBITS        00008000 008000 00000c 00  AX  0   0  4
  [ 2] .text             PROGBITS        0000800c 00800c 0000c8 00  AX  0   0  4
  [ 3] .fini             PROGBITS        000080d4 0080d4 00000c 00  AX  0   0  4
  [ 4] .eh_frame         PROGBITS        000080e0 0080e0 000004 00   A  0   0  4
  [ 5] .init_array       INIT_ARRAY      000100e4 0080e4 000004 00  WA  0   0  4
  [ 6] .fini_array       FINI_ARRAY      000100e8 0080e8 000004 00  WA  0   0  4
  [ 7] .jcr              PROGBITS        000100ec 0080ec 000004 00  WA  0   0  4
  [ 8] .bss              NOBITS          000100f0 0080f0 00001c 00  WA  0   0  4
  [ 9] .comment          PROGBITS        00000000 0080f0 000030 01  MS  0   0  1
  [10] .debug_aranges    PROGBITS        00000000 008120 000388 00      0   0  8
  [11] .debug_info       PROGBITS        00000000 0084a8 004526 00      0   0  1
  [12] .debug_abbrev     PROGBITS        00000000 00c9ce 001211 00      0   0  1
  [13] .debug_line       PROGBITS        00000000 00dbdf 00452a 00      0   0  1
  [14] .debug_frame      PROGBITS        00000000 01210c 000894 00      0   0  4
  [15] .debug_str        PROGBITS        00000000 0129a0 050a54 01  MS  0   0  1
  [16] .debug_ranges     PROGBITS        00000000 0633f8 000290 00      0   0  8
  [17] .debug_macro      PROGBITS        00000000 063688 00df07 00      0   0  1
  [18] .ARM.attributes   ARM_ATTRIBUTES  00000000 07158f 000027 00      0   0  1
  [19] .shstrtab         STRTAB          00000000 0715b6 0000da 00      0   0  1
  [20] .symtab           SYMTAB          00000000 071a00 000a00 10     21 150  4
  [21] .strtab           STRTAB          00000000 072400 0006eb 00      0   0  1

[Dr. Sommer (Gast)]

JensH schrieb:
> Aber eines hab ich rausgefunden, dass mit arm-none-eabi-objdump -d nur
> sehr wenig angezeigt wird, mit arm-none-eabi-objdump -D aber alles.
Ja das muss so, -d disassemblisiert nur die Sections die Code enthalten, 
und nicht Daten-Sections. Mit -s wird auch der Inhalt der Daten-Sections 
hexadezimal angezeigt.

JensH schrieb:
> Es scheint so, als ob fast alles in Speicherbereichen steht, die nicht
> gültig sind. Vielleicht ist beim Linkerfile was daneben gegangen.
Nicht ungültig, nur halt kein Code drin. Meinst das Linkerscript? 
Möglich. Oder in der ISR-(Vector)-Definition.

JensH schrieb:
> [ 2] .text             PROGBITS        0000800c 00800c 0000c8 00  AX
> 0   0  4
200 Byte, recht wenig...

[JensH (Gast)]

Hallo Dr. Sommer,
Das Linkerskript wurde nicht geladen, weil ein Punkt zuviel im Verweis 
darauf war.
F****
5 Stunden rumgesucht. Ich schalt die Kiste jetzt für heute aus. War mir 
zuviel :)

Vielen Dank. Du konntest zwar meinen Punkt nicht sehen, hast mich aber 
auf den richtigen Weg gebracht.

Schönen Abend noch!

[Dr. Sommer (Gast)]

JensH schrieb:
> Das Linkerskript wurde nicht geladen, weil ein Punkt zuviel im Verweis
> darauf war.
Gibts denn da keine Fehlermeldung?