WARNUNG: Debian gcc-avr 4.8.2-1 bringt lästigen Bug

Michael Reinelt schrieb:
> Ich bin jedenfalls wieder auf 4.8-2 zurück.

Du könntest natürlich auch einfach den Compiler selbst bauen und dann
den entsprechenden Fix bereits mit reinziehen. ;-)

Jörg Wunsch schrieb:
> Michael Reinelt schrieb:
>> Ich bin jedenfalls wieder auf 4.8-2 zurück.
>
> Du könntest natürlich auch einfach den Compiler selbst bauen und dann
> den entsprechenden Fix bereits mit reinziehen. ;-)

Ganz kurz (um genau zu sein 1.0/F_CPU Sekunden) hab ich sogar daran 
gedacht ;-)

Jörg Wunsch schrieb:
> Du könntest natürlich auch einfach den Compiler selbst bauen und dann
> den entsprechenden Fix bereits mit reinziehen. ;-)

Es ist - hmm - etwas zeitaufwendig, wenn man sich als gelegentlicher 
Compilerselbst(bio)bauer die benötigten (welche denn?) Patches 
zusammensuchen will.

Konrad S. schrieb:
> Es ist - hmm - etwas zeitaufwendig, wenn man sich als gelegentlicher
> Compilerselbst(bio)bauer die benötigten (welche denn?) Patches
> zusammensuchen will.

Das war glaub ich auch nicht wirklich ernst gemeint :-)

Konrad S. schrieb:
> Es ist - hmm - etwas zeitaufwendig, wenn man sich als gelegentlicher
> Compilerselbst(bio)bauer die benötigten (welche denn?) Patches
> zusammensuchen will.

Naja, diejenigen, die für die jeweilige Distributionsversion benutzt
worden sind, sollten doch einfach zu beschaffen sein, oder?  Man muss
doch eigentlich nur das nachvollziehen, was der Distributor da getan
hat, dann den gewünschten zusätzlichen Patch beilegen und alles nochmal
compilieren.

Kannst du nicht einfach mit -w linken?

Johann L. schrieb:
> Kannst du nicht einfach mit -w linken?

Könnte ich sicher, wenn ich wüsste was -w tut. Meine gcc-ManPage kennts 
mal nicht (oder ich finds nicht), ld-manpage auch nicht.

Wo und wie würde ich das aufrufen? Vermutlich bei -Wl,<linker options>

Jörg Wunsch schrieb:
> Konrad S. schrieb:
>> Es ist - hmm - etwas zeitaufwendig, wenn man sich als gelegentlicher
>> Compilerselbst(bio)bauer die benötigten (welche denn?) Patches
>> zusammensuchen will.
>
> Naja, diejenigen, die für die jeweilige Distributionsversion benutzt
> worden sind, sollten doch einfach zu beschaffen sein, oder?  Man muss
> doch eigentlich nur das nachvollziehen, was der Distributor da getan
> hat, dann den gewünschten zusätzlichen Patch beilegen und alles nochmal
> compilieren.

Ja. Normalerweise gibt es zu jedem kompilierten Paket die entsprechenden 
Quellpakete, aus denen die Pakete erzeugt wurden.

Dann noch den Fix einpatchen und los geht's :-)

Der Aufwand hält sich im Rahmen.

Chris D. schrieb:

> Der Aufwand hält sich im Rahmen.

Ja, wenn man die ganze Toolchain und -dev Pakete schon drauf hat. 
Ansonsten tu ich mir das nur an wenns wirklich dringend ist.

Michael Reinelt schrieb:
> Johann L. schrieb:
>> Kannst du nicht einfach mit -w linken?
>
> Könnte ich sicher, wenn ich wüsste was -w tut. Meine gcc-ManPage kennts
> mal nicht (oder ich finds nicht), ld-manpage auch nicht.

1

-w

2

    Inhibit all warning messages.

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html#index-w-250

Also normal compilieren mit all den -W Warnungen die du magst, und 
während dem LTO-Lauf die Warnungen deaktivieren.

Ist zwar nur ein Work-Around, aber wenn's eben ein Problem in den Tools 
gibt, braucht's eben nen Work-Around.

Chris D. schrieb:
> Dann noch den Fix einpatchen und los geht's :-)
>
> Der Aufwand hält sich im Rahmen.

Ich würd mal sagen, 99% der Compilerbenutzer wissen nicht, wie man einen 
Compiler selber compiliert.

Johann L. schrieb:
>

1

> -w

2

>     Inhibit all warning messages.

3

>

Das war vorher nicht da! ich schwöre! :-)
keine Ahnung wie ich das übersehen konnte...

> Also normal compilieren mit all den -W Warnungen die du magst, und
> während dem LTO-Lauf die Warnungen deaktivieren.

Hmmm... da ich erst seit kurzem mit LTO arbeite (dank einem 
interessanten Thread hier) hab ich keinen "extra LTO-Lauf" (ist 
vielleicht ein Fehler?)

Mein makefile sieht so aus:

1

MCU     = atmega328p

2

F_CPU   = 16000000UL

3

4

SOURCES = main.c i2c_master.c dog.c uart.c qprintf.c

5

6

CFLAGS = -W -Wall -Wextra -std=gnu99 -Os -flto -fshort-enums -fno-strict-aliasing -fverbose-asm -save-temps -Wl,-Os,-flto,--relax,--gc-sections

7

8

COMPILE = avr-gcc $(CFLAGS) -DF_CPU=$(F_CPU) -mmcu=$(MCU)

9

10

11

all:  main.hex

12

13

main.elf: $(SOURCES)

14

  $(COMPILE) -o main.elf $(SOURCES) -lm

15

16

main.hex: main.elf

17

  avr-objcopy -O ihex -j .text -j .data main.elf main.hex

18

  avr-size --format=avr --mcu=$(MCU) main.elf

19

20

size:  main.elf

21

  avr-nm --size-sort --print-size -td main.elf

22

23

flash:  all

24

  avrdude -c stk500v2 -P /dev/ttyUSB0 -p atmega328p -q -U flash:w:main.hex:i

25

26

fuse:

27

  avrdude -c stk500v2 -P /dev/ttyUSB0 -p atmega328p -q -U lfuse:w:0xff:m 

28

  avrdude -c stk500v2 -P /dev/ttyUSB0 -p atmega328p -q -U hfuse:w:0xd0:m 

29

  avrdude -c stk500v2 -P /dev/ttyUSB0 -p atmega328p -q -U efuse:w:0x07:m 

30

31

check:

32

  avrdude -c stk500v2 -P /dev/ttyUSB0 -p atmega328p -n -v

33

34

clean:

35

  rm -f main.hex main.elf *.o *.s *.i *.res *.out *~

im wesentlichen gibts also eine Regel die alles macht (main.elf) und da 
mag ich verständlicherweise keine Warnings unterdrücken...

Peter Dannegger schrieb:
> Ich würd mal sagen, 99% der Compilerbenutzer wissen nicht, wie man einen
> Compiler selber compiliert.

Hab mir schon gedacht, dass ich einer Minderheit angehöre. :-)

Chris D. schrieb:
> Ja. Normalerweise gibt es zu jedem kompilierten Paket die entsprechenden
> Quellpakete, aus denen die Pakete erzeugt wurden.

Die zuhause für AVR-Entwicklung verwendetete Distribution macht bei 
gcc-4.4 Schluss. Damit ist kein Blumentopf zu gewinnen. Ich könnte 
natürlich die Paketquellen einer anderen Distribution zerpflücken ...

Welche Distribution ist denn bei den gcc-Versionen immer vorne mit 
dabei? Den gcc-4.8.1 habe ich schon - ungepatcht allerdings.

Konrad S. schrieb:
> Welche Distribution ist denn bei den gcc-Versionen immer vorne mit
> dabei? Den gcc-4.8.1 habe ich schon - ungepatcht allerdings.

ich bin da mit Debian eigentlich sehr zufrieden, sofern du dich aus dem 
stabilen Bereich raustraust. Das geht aber mit "Pinning" sehr gut und 
komfortabel. Ich hab einen mix aus Stable (sehr wenig), Testing (das 
meiste), Unstable (sehr wenig) und von Fall zu Fall probier ich gerne 
mal ein Paket aus Experimental aus.

beim gcc-avr siehts da momentan so aus:
stable: 4.7.2
testing, unstable, experimental: 4.8-2.1

der "normale" gcc ist im experimental schon auf 4.9

Die o.g. überflüssige Warnung tritt ausschließlich mit 4.8.2 auf:

http://gcc.gnu.org/PR59396

Michael Reinelt schrieb:
> ich bin da mit Debian eigentlich sehr zufrieden, sofern du dich aus dem
> stabilen Bereich raustraust. Das geht aber mit "Pinning" sehr gut und
> komfortabel. Ich hab einen mix aus Stable (sehr wenig), Testing (das
> meiste), Unstable (sehr wenig) und von Fall zu Fall probier ich gerne
> mal ein Paket aus Experimental aus.

Danke, dann schau ich mal in die Richtung. Ich hole mir da dann eh nur 
die Quelltext-Pakete, denn mein aktuelles System bleibt drauf, solange 
es dafür Security-Updates gibt. Da sind 'ne Menge (angepasste, selbst 
compilierte und selbst geschriebene) Sachen drauf, die wunderbar laufen, 
solange mir Updates nicht wieder was zerlegen (VDR ist da etwas 
anfällig).

Konrad S. schrieb:
>(VDR ist da etwas anfällig).
Ah ja, das kommt mir bekannt vor :-) extrem schädlich für den WAF wenn 
VDR am Entwicklungsrechner läuft. Da hab ich sehr schnell die 
Budgetfreigabe der Regierung für eigenen Rechner bekommen ;-)

Johann L. schrieb:
> Also normal compilieren mit all den -W Warnungen die du magst, und
> während dem LTO-Lauf die Warnungen deaktivieren.


Johann, falls du hier nochmal reinliest und etwas Zeit hast, könntest du 
mir erläutern wie das mit dem "LTO-Lauf" in meinem Makefile (siehe 
weiter oben) aussehen sollte? Danke!

AVerr schrieb:
> Martin schrieb:
>> ... Mein Auto braucht Diesel ...
> Für den Ottonormalverbraucher ...

Martin ist aber Dieselnormalverbraucher und damit fährt er ganz gut. ;-)