gcc 5 mit --gc-sections killt interrupt vectoren

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Hallo Leute!

Habe mich gerade mit dem gcc 5.3 geärgert... irgendwie optimiert er mit 
meine interrupt vectoren raus wenn man mit --gc-sections (+ 
-ffunction-sections/-fdata-sections) arbeitet.

Anscheinend liegt das am neuen linker (zumindest interpretiere ich den 
letzten post in 
http://stackoverflow.com/questions/23668247/gcc-warning-used-attribute-ignored 
so)...


Die Lösung war für mich folgende (diff gegen svn):

--- interrupt.h_orig    2016-01-25 21:55:47.427354891 +0100
+++ interrupt.h 2016-01-25 22:04:47.377367723 +0100
@@ -125,10 +125,14 @@
 #  define ISR(vector, [attributes])
 #else  /* real code */
 
-#if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4)
-#  define __INTR_ATTRS used, externally_visible
-#else /* GCC < 4.1 */
-#  define __INTR_ATTRS used
+#if (__GNUC__ > 4)
+#    define __INTR_ATTRS used, externally_visible, section (".vectors")
+#else
+#  if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
+#    define __INTR_ATTRS used, externally_visible
+#  else /* GCC < 4.1 */
+#    define __INTR_ATTRS used
+#  endif
 #endif
 
 #ifdef __cplusplus

irgend jemand eine schöner Lösung parat?

Das linker-script hat übrigens den notwendigen KEEP drinnen...

73

[Johann L. (gjlayde)]

ALso jetzt GCC oder LD der Bösewicht?

Mit GCC 5.2.1, Binutils 2.25.51 und folgendem Programm kann ich das 
nicht bestätigen:

#include <avr/interrupt.h>

ISR (INT0_vect) {}

int main;

Präprocessed:

void __vector_1 (void) __attribute__ ((signal,used, externally_visible)) ; void __vector_1 (void) 
               {}
int main;

wobei compiliert mit

avr-gcc -mmcu=attiny44 -Os foo.c -o foo.elf -save-temps -Wl,-Map,foo.map -Wl,--gc-sections -ffunction-sections

Im Disassembly von foo.elf steht dann auch brav __vector_1 drinne.

Ich zieh dir jetzt mal nicht jeden Wurm einzeln aus der Nase; ich geh 
mal davon aus dass du weisst, was andere brauchen um dein Problem 
nachzuvollziehen.

[Johann L. (gjlayde)]

...und die ISRs gehören NICHT nach .vectors!

In .vectors stehen die IRQ-Vektoren, die einen (R)JMP zu jeweiligen ISR 
(bzw. __bad_interrupt als Default) enthalten.

Was treibst du da???

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

ok... .vectors ist falsch... typischer fall von RTFM...

Das Grundproblem bleibt.

Ohne Patch:

00000000 l    d  .text  00000000 .text
00800060 l    d  .data  00000000 .data
00000000 l    df *ABS*  00000000 _clear_bss.o
0000000a l       .text  00000000 .do_clear_bss_start
00000008 l       .text  00000000 .do_clear_bss_loop
00000000 l    df *ABS*  00000000 
00000010 l       *ABS*  00000000 __data_load_start
00000000 g       .text  00000000 __trampolines_start
00000010 g       .text  00000000 _etext
00000010 g       *ABS*  00000000 __data_load_end
00000000 g       .text  00000000 __trampolines_end
00000000 g       .text  00000000 __dtors_end
00800060 g       .data  00000000 __bss_end
00000000 g       .text  00000010 .hidden __do_clear_bss
00810000 g       .data  00000000 __eeprom_end
00000000 g       .text  00000000 __ctors_start
00800060 g       .data  00000000 __bss_start
00000000 g       .text  00000000 __dtors_start
00000000 g       .text  00000000 __ctors_end
00800060 g       .data  00000000 _edata
00800060 g       .data  00000000 _end

Mit patch:

00000000 l    d  .text  00000000 .text
00800060 l    d  .data  00000000 .data
00000000 l    d  .comment       00000000 .comment
00000000 l    df *ABS*  00000000 main.c
0000003e l       *ABS*  00000000 __SP_H__
0000003d l       *ABS*  00000000 __SP_L__
0000003f l       *ABS*  00000000 __SREG__
00000000 l       *ABS*  00000000 __tmp_reg__
00000001 l       *ABS*  00000000 __zero_reg__
00000000 l    df *ABS*  00000000 _clear_bss.o
0000003a l       .text  00000000 .do_clear_bss_start
00000038 l       .text  00000000 .do_clear_bss_loop
00000000 l    df *ABS*  00000000 
00000040 l       *ABS*  00000000 __data_load_start
00000030 g       .text  00000000 __trampolines_start
00000040 g       .text  00000000 _etext
00000040 g       *ABS*  00000000 __data_load_end
00000030 g       .text  00000000 __trampolines_end
00000030 g       .text  00000000 __dtors_end
00800060 g       .data  00000000 __bss_end
00000000 g     F .text  00000030 __vector_17
00000030 g       .text  00000010 .hidden __do_clear_bss
00810000 g       .data  00000000 __eeprom_end
00000030 g       .text  00000000 __ctors_start
00800060 g       .data  00000000 __bss_start
00000030 g       .text  00000000 __dtors_start
00000030 g       .text  00000000 __ctors_end
00800060 g       .data  00000000 _edata
00800060 g       .data  00000000 _end

ohne --gc-sectiions:

00000000 l    d  .text  00000000 .text
00800060 l    d  .data  00000000 .data
00800060 l    d  .bss   00000000 .bss
00000000 l    d  .comment       00000000 .comment
00000000 l    df *ABS*  00000000 _clear_bss.o
0000000a l       .text  00000000 .do_clear_bss_start
00000008 l       .text  00000000 .do_clear_bss_loop
00000000 l    df *ABS*  00000000 main.c
0000003e l       *ABS*  00000000 __SP_H__
0000003d l       *ABS*  00000000 __SP_L__
0000003f l       *ABS*  00000000 __SREG__
00000000 l       *ABS*  00000000 __tmp_reg__
00000001 l       *ABS*  00000000 __zero_reg__
00000000 l    df *ABS*  00000000 _divmodhi4.o
000000ac l       .text  00000000 __divmodhi4_neg1
000000b4 l       .text  00000000 __divmodhi4_neg2
000000ba l       .text  00000000 __divmodhi4_exit
00000000 l    df *ABS*  00000000 _udivmodhi4.o
000000d2 l       .text  00000000 __udivmodhi4_ep
000000c4 l       .text  00000000 __udivmodhi4_loop
0000003e g     F .text  00000028 WriteByteToBuffer
000000bc g       .text  0000002c .hidden __udivmodhi4
00000000 g       .text  00000000 __trampolines_start
000000e8 g       .text  00000000 _etext
000000e8 g       *ABS*  00000000 __data_load_end
00000000 g       .text  00000000 __trampolines_end
000000e8 g       *ABS*  00000000 __data_load_start
00000000 g       .text  00000000 __dtors_end
008000e8 g       .bss   00000000 __bss_end
00000066 g     F .text  00000030 __vector_17
00000000 g       .text  00000010 .hidden __do_clear_bss
00810000 g       .comment       00000000 __eeprom_end
00000010 g     F .text  00000030 NextByteFromBuffer
00000096 g       .text  00000026 .hidden __divmodhi4
00000000 g       .text  00000000 __ctors_start
00800060 g       .bss   00000000 __bss_start
00800060 g     O .bss   00000044 SendBuffer
008000a4 g     O .bss   00000044 ReceiveBuffer
00000000 g       .text  00000000 __dtors_start
00000000 g       .text  00000000 __ctors_end
00800060 g       .data  00000000 _edata
008000e8 g       .comment       00000000 _end
00000096 g       .text  00000000 .hidden _div

GCC aufruf:
avr-gcc -std=gnu11 -Os -Wall -Wextra -Wconversion -fomit-frame-pointer 
-c -fmessage-length=0 -mmcu=atmega328p      -ffunction-sections 
-fdata-sections -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"


Linking:
avr-gcc -Xlinker --gc-sections -Xlinker --relax -Xlinker --strip-debug



Irgendwas mag er also beim linking nicht...

73

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Mir fällt gerade auf, dass nicht einmal main() mitgelinkt wird....

es wird immer schräger...

73

[Johann L. (gjlayde)]

Hans W. schrieb:
> Linking:
> avr-gcc -Xlinker --gc-sections -Xlinker --relax -Xlinker --strip-debug

Wie wär's dem Linker Objekte wie main.o zu überreichen?

Und wie wär's mit -mmcu=?

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Sorry, habe die Parameter gekürzt... aber der invoke sollte passen...

00:29:04 **** Build of configuration Debug for project BeeStalkerMk1Firmware ****
make all 
Building file: ../main.c
Invoking: Cross GCC Compiler
avr-gcc -std=gnu11 -Os -Wall -Wextra -Wconversion -mmcu=atmega328p -ffunction-sections -fdata-sections -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
Finished building: ../main.c
 
Building target: BeeStalkerMk1Firmware
Invoking: Cross GCC Linker
avr-gcc -Xlinker -Map=output.map -Xlinker --gc-sections -Xlinker --strip-debug -o "BeeStalkerMk1Firmware"  ./main.o   
Finished building target: BeeStalkerMk1Firmware
 
make --no-print-directory post-build
avr-objcopy -O ihex -j .text -j .data -j .vectors BeeStalkerMk1Firmware  BeeStalkerMk1Firmware.hex; avr-objdump -D BeeStalkerMk1Firmware > BeeStalkerMk1Firmware.lst
 

00:29:04 Build Finished (took 111ms)

Damit bekomme ich kein vernünftiges binary.

Dagegen liefert

00:31:32 **** Build of configuration Debug for project BeeStalkerMk1Firmware ****
make all 
Building file: ../main.c
Invoking: Cross GCC Compiler
avr-gcc -std=gnu11 -Os -Wall -Wextra -Wconversion -mmcu=atmega328p -flto -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
Finished building: ../main.c
 
Building target: BeeStalkerMk1Firmware
Invoking: Cross GCC Linker
avr-gcc -Xlinker -Map=output.map -Xlinker --strip-debug -o "BeeStalkerMk1Firmware"  ./main.o   
Finished building target: BeeStalkerMk1Firmware
 
make --no-print-directory post-build
avr-objcopy -O ihex -j .text -j .data -j .vectors BeeStalkerMk1Firmware  BeeStalkerMk1Firmware.hex; avr-objdump -D BeeStalkerMk1Firmware > BeeStalkerMk1Firmware.lst
 

00:31:32 Build Finished (took 124ms)

genau das was ich will....


Spannend...

73

[g457 (Gast)]

> Sorry, habe die Parameter gekürzt... aber der invoke sollte passen...

Da fehlen immernoch Parameter wie mir scheint.

[Hans (Gast)]

das ist copy/paste aus eclipse...

mir ist beim Vergleichen mit den Beispielmakefiles aus der 
Artikelsammlung nichts wesentliches aufgefallen.

73

[guest (Gast)]

Um mal Johann zu zitieren:
Johann L. schrieb:
> Und wie wär's mit -mmcu=?

Scheint bei Deinen Linkeraufruf immer noch zu fehlen.

[Johann L. (gjlayde)]

guest schrieb:
> Um mal Johann zu zitieren:
> Johann L. schrieb:
>> Und wie wär's mit -mmcu=?
>
> Scheint bei Deinen Linkeraufruf immer noch zu fehlen.

Damit erklärt sich auch wrum die ISR entsorgt wird:

Kein -mmcu= ==> es wird kein Startup-Code gelinkt ==> .vectors ist leer 
==> __vector_X wird nicht referenziert ==> __vector_X wird entsorgt.

Mit section(".vectors") kommt die ISR in eine KEEP-Section und das 
Problem schein behoben.  Dass so ein Code funktioniert würd ich stark 
bezweifeln.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Klingt logisch.

Aber es funktioniert offensichtlich mit -flto (und ohne optimizer auch).


Mit -mmcu beim linking kommt folgendes:

21:56:22 **** Incremental Build of configuration Debug for project BeeStalkerMk1Firmware ****
make all 
Building file: ../main.c
Invoking: Cross GCC Compiler
avr-gcc -std=gnu11 -Os -Wall -Wextra -Wconversion -mmcu=atmega328p -ffunction-sections -fdata-sections -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
Finished building: ../main.c
 
Building target: BeeStalkerMk1Firmware
Invoking: Cross GCC Linker
avr-gcc -mmcu=atmega328p -Xlinker -Map=output.map -Xlinker --gc-sections -Xlinker --strip-debug -o "BeeStalkerMk1Firmware"  ./main.o   
./main.o: In function `__vector_22':
(.text+0x8c): multiple definition of `__bad_interrupt'
makefile:29: recipe for target 'BeeStalkerMk1Firmware' failed
/usr/lib/gcc/avr/5.3.0/../../../../avr/lib/avr5/crtatmega328p.o:(.text+0x0): first defined here
./main.o: In function `__vectors':
(.text+0x0): multiple definition of `__vectors'
/usr/lib/gcc/avr/5.3.0/../../../../avr/lib/avr5/crtatmega328p.o:(.vectors+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [BeeStalkerMk1Firmware] Error 1

21:56:22 Build Finished (took 116ms)

Irgendwas ist faul.

zugegebenermaßen vertraue ich meinem build-system gerade nicht... zuviel 
selbst dazucompiliert... wird zeit für slackware 14.2 ...

73

[Johann L. (gjlayde)]

Sachma was hast du da für eine komische Quelle?  Nimm erst mal das 
.vectors wieder raus du dass ISRs nach .text kommen.  Oder hast du noch 
mehr an Headern gepimpt?

Wieso definiert du __vectors?

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

das ist eigentlich alles vanilla ... avr-libc SVN, binutils 2.25, 
gcc5.3!

nur die avr-size ist gepatcht.

ich glaube ich sollte mal in einer vm das auf einem sauberen system neu 
kompilieren... möglicherweise ist da was übergeblieben...

73

[Johann L. (gjlayde)]

Mit Quelle meine ich deine Quelle main.c.  Nach dem Fehler zu urteilen 
machst du da komische Sachen.

Als erstes kannst du den asm Code den gcc gegen den älterer Versionen 
vergleichen, ditto Disassembly vom gas.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Nein mache ich nicht.

irgendwas ist an der toolchain faul... aber recompile muss warten.

einer meiner VPS muss umziehen...

73

/*
 * main.c
 *
 *  Created on: Jan 25, 2016
 *      Author: hans
 */

#include <avr/io.h>
#include <avr/interrupt.h>


#include <stdint.h>
#include <stdbool.h>

volatile uint8_t CurrentCommand;

ISR(SPI_STC_vect) {
  unsigned char Input;
  Input=SPDR;

  CurrentCommand=Input;
  SPDR=0x06; //ASCII ACK!
}


int main() {

  while(1) {
    switch (CurrentCommand) {
    case 0: //Idle
      break;
    case 1: //Enter Sleep
      break;
    case 2: //Read Channel 1
      break;
    case 3: //Read Channel 2
      break;
    default:
      break;
    }


    //sleep;
  }
  return 0;
}

[Johann L. (gjlayde)]

Und den Hack in interrupt.h hast du wieder rückgängig gemacht?

[hans (Gast)]

Ja, alles wieder wie am Anfang...

Wie gesagt, interessanterweise gehts mit LTO aber nicht mit dem garbage 
collector....

[Johann L. (gjlayde)]

Was ich nicht verstehe ist das:

> avr-gcc -std=gnu11 -Os -Wall -Wextra -Wconversion -mmcu=atmega328p
> -ffunction-sections -fdata-sections -MMD -MP -MF"main.d" -MT"main.d"
> -o "main.o" "../main.c"

Du nennst das erzeugte Executable "main.o" und linkst es kann abermals 
genen den Startup-Code und nennst das dann "BeeStalkerMk1Firmware".

Endung .o wird ünlicherweise für Object-Files verwendet, d.h. Sachen, 
die mit -c compiliert und nicht gelinkt sind.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Hmmm logische Erklärung... Wenn man dem Map-File glaubt funktioniert es 
auch.

Danke!

Wobei sich für mich die Frage stellt warum das (ohne -c) default bei 
eclipse (Keppler) ist...

73