AVR-GCC: Variable wir leider weg optimiert

ChrisMicro schrieb:
>>Autor: Benji (Gast)
>>volatile davor packen.
> Das habe ich schon probiert. Bringt nichts, wird trotzdem weg optimiert.

volatile sorgt dafür, dass Zugriffe auf die Variable nicht 
wegoptimiert, sondern so durchgeführt werden, wie sie im Code stehen. Es 
gibt aber keine Zugriffe. Deshalb bringt volatile hier nichts.

ChrisMicro schrieb:
> uint16_t  boot_reset __attribute__((section(".bootreset")))= 0xCBFF;

Wie soll denn der Wert 0xCBFF überhaupt in deine Variable reinkommen?

Der normale .data-Loader im Startup-Code hat keine Ahnung, dass er
das mit tun sollte.

ChrisMicro schrieb:
> das ganze Prinzip habe ich aus dem Bootloader Artikel übernommen und
> habe gehofft, dass es recht unproblematisch funktioniert

Bei denen sind es aber Flash-Daten.  Ich habe den Eindruck, dass
du versuchst, das im RAM anzulegen (also wirklich als Variable).

Da musst du dir schon die Frage stellen, auf welche Weise die Werte
dann auch ins RAM gelangen.

ChrisMicro schrieb:
>>ich versteht immer noch nicht was du damit machst. Irgendwie musst du
>>sie doch mal verwenden, sonst macht das doch alles keinen sinn.
>
> Sie wird als Reset Vector für einen Bootloader verwendet, genau wie hier
> im Abschnitt Speicherlayout beschrieben:

Das erscheint mir aber extrem hackish. Ich könnte mir vorstellen, dass
dieser Trick mit irgendeiner alten Toolchain-Version funktioniert hat,
aber nicht mehr mit der aktuellen.

Warum nutzt du dafür nicht den Inline-Assembler? Dann musst du auch
nicht den Hexcode für den RJMP-Befehl explizit in dein Programm
schreiben.

ChrisMicro schrieb:

> Wie kann ich das ändern?

Ich habe gerade ein Ähnliches Problem bei einem nrf52 gelöst, in dem ich 
den Wert einfach im linker script beschrieben habe:

1

MEMORY

2

{

3

    FLASH (rx) : ORIGIN = BOOTLOADER_CODE_BASE, LENGTH = BOOTLOADER_CODE_SIZE

4

    RAM (rwx)  : ORIGIN = BOOTLOADER_RAM_BASE, LENGTH = BOOTLOADER_RAM_SIZE

5

    UICR (r)   : ORIGIN = 0x10001000, LENGTH = 0x400

6

}

7

8

...

9

10

SECTIONS {

11

    .bootloader_addr 0x10001014 :

12

    {

13

        LONG(BOOTLOADER_CODE_BASE)

14

    } > UICR

15

}

ChrisMicro schrieb:
> Debug mit Debug-Wire zeigt, dass der Wert im Flash steht ( siehe Bild ).

Dann verstehe ich deine Aussage („wird wegoptimiert“) nicht.  Wenn
der Wert im Flash liegt, dann ist er doch nicht „wegoptimiert“.

Aber ehrlich gesagt, ist mir auch das gesamte Anliegen nicht so recht
klar.

ChrisMicro schrieb:
> Er wird nur dann nicht "wegoptimiert" wenn in der "main" dieser nicht
> benutzte Hilfszugriff steht:

Dann wurde dir aber schon genannt:

1

__attribute__((used))

Sag mal, benutzt du beim Linken sowas wie -Wl,--gc-sections?  Dann
müsstest du dich nicht weiter wundern …

ChrisMicro schrieb:
> Es scheint also kein so einfaches Problem zu sein.
> Tendenziell würde ich es lieber im Code haben und das Linker-Script eher
> weniger verändern.

Naja, jetzt hast Du die Definition dieser Konstanten im Flash im Code 
und in den Linker-Parametern stehen. Wenn Du es im Linker-Script 
definierst. Aber wir Jörg auch schon festgestellt hat: Die Konstante 
wird nicht weg optimiert. Wenn irgend etwas nicht funktioniert, dann 
scheint es ein anderes Problem zu sein.

ChrisMicro schrieb:
>>Dann wurde dir aber schon genannt:
>>__attribute__((used))
> Ja, das habe ich hier schon so probiert:
> Beitrag "Re: AVR-GCC: Variable wir leider weg optimiert"
> Es hat aber nicht funktioniert. Ist es syntaktisch richtig? Es wurde
> kein Warning geworfen.

Guck doch einfach mal ins Hex-File. Wenn es da drinnen steht, dann hat 
"es" funktioniert.

ChrisMicro schrieb:
> Ohne -Wl, --gc-sections wird es nicht mehr weg optimiert.

Dann macht der Linker genau das, was du ihm gesagt hast.

Mich wundert allerdings, warum das "used"-Attribut nicht dagegen
helfen sollte.

> Allerdings würde ich nicht sagen, dass ich "--gc-sections" benutzt habe,
> sondern Atmel-Studio7.

Kann gut sein.  Diese Optionen (zusammen mit -ffunction-sections)
sind der Faulheit der Leute geschuldet, sauberen Code zu schreiben,
bei dem man nur solche Dinge auch tatsächlich in den Quellen hat,
die man am Ende benötigt.

ChrisMicro schrieb:
> Aber leider wird die Variable "boot_reset" einfach weg optimiert.
>
> Wie kann ich das ändern?

Du brauchst dann ein passendes Linker Skript mit einem passenden KEEP() 
Statement.

Deig mal dein aktuelles Linker Skript.

ChrisMicro schrieb:
>>Warum nutzt du dafür nicht den Inline-Assembler?
> Ich weiß leider nicht, wie es geht.

Ich habe den von dir velinkten Artikel nicht komplett gelesen, deswegen
weiß ich nicht im Detail, worauf es bei dem Sprung genau ankommt. Es
scheint aber so, dass er

1. an der Adresse 0 liegen muss (Reset-Vektor) und

2. an den Anfang der (in einen höheren Adressbereich verschobenen)
   Vektortabelle springen soll, wo ein von der Toolchain generierter
   Sprung zum eigentlich Programmstart steht.

Beides erreichts du mit folgender Funktion:

1

void boot_reset(void) __attribute__((naked, section(".bootreset")));

2

void boot_reset(void) {

3

  __asm__(" rjmp __vectors");

4

}

Mit

1

$ avr-gcc -mmcu=attiny85 -Wall -Os -Wl,--section-start=.text=0x1800 \

2

  -Wl,--section-start=.bootreset=0 -o bltest  bltest.c

3

$ avr-objdump -d bltest

4

...

5

Disassembly of section .text:

6

7

00001800 <__vectors>:

8

    1800:       0e c0           rjmp    .+28            ; 0x181e <__ctors_end>

9

...

10

Disassembly of section .bootreset:

11

12

00000000 <boot_reset>:

13

   0:   ff cb           rjmp    .-2050          ; 0xfffff800 <__eeprom_end+0xff7ef800>

Mit -Wl,--gc-sections hast du auch hier das Problem, dass der Linker die
Section .bootreset wegoptimiert. Das used-Attribut wirkt sich nur auf
den Compiler, nicht aber auf den Linker aus, weswegen es hier nicht den
gewünschten Effekt hat. Du musst entweder die Option -Wl,--gc-sections
weglassen, oder ins Linkerscript eine entsprechende KEEP-Anweisung
einfügen.

Jörg W. schrieb:
> ChrisMicro schrieb:
>> Ohne -Wl, --gc-sections wird es nicht mehr weg optimiert.
>
> Dann macht der Linker genau das, was du ihm gesagt hast.
>
> Mich wundert allerdings, warum das "used"-Attribut nicht dagegen
> helfen sollte.

Wirkt das used-Attribut nicht nur auf den Compiler und dessen 
Optimierer?
Der Linker weiß doch davon garnichts. Oder?

Steffen R. schrieb:
> Wirkt das used-Attribut nicht nur auf den Compiler und dessen
> Optimierer?

Stimmt.  Ich nahm an, dass er das auch dem Linker weiterreichen würde,
aber das ist nicht der Fall.

Damit ist klar, warum der Linker das bei --gc-sections rauskickt.

Jörg W. schrieb:
> ChrisMicro schrieb:
>> Ohne -Wl, --gc-sections wird es nicht mehr weg optimiert.
>
> Dann macht der Linker genau das, was du ihm gesagt hast.
>
> Mich wundert allerdings, warum das "used"-Attribut nicht dagegen
> helfen sollte.

Weil "used" nur auf den Compiler wirkt: Das Objekt wird nicht verwendet, 
wegen "used" aber dennoch angelegt — eine used-Direktive für gas gibt es 
nicht.  Da es nicht referenziert wird und nicht KEEP ist, wird es vom 
Linker entsorgt.

Referenzieren bringt auch nur dann was, wenn es wirklich eine "Senke" 
für die Verwendung gibt, die der Compiler nicht wegoptimieren kann. 
Eine zu simple Verwendung kann durchaus ebenfalls vom Compiler als 
solche erkannt und somit entsorgt werden.

deklarier es als const (oder diese progmem Sache bei avr), sonst landet 
es nicht im Flash sondern irgendwo im RAM.


Hier ist ein funktionierender  Beispielschnipsel (aus nem ARM Startup 
code), es gibt keinen Grund warum das nicht auch bei AVR funktionieren 
sollte wenn man den Compiler davon überzeugen kann daß er die Konstante 
in den Flash legen soll:

1

#define SECT_FLASHCONF          __attribute__((section(".kinetis_flash_config_field"), __used__))

2

3

4

5

SECT_FLASHCONF const long __flash_config[4] = {

6

    0xffffffff,

7

    0xffffffff,

8

    0xffffffff,

9

    0xfffeffff,

10

};

Bernd K. schrieb:
> deklarier es als const (oder diese progmem Sache bei avr), sonst landet
> es nicht im Flash sondern irgendwo im RAM.

"const" ist dafür völlig belanglos.  Bei einem AVR landen auch
"const" deklarierte Variable keineswegs automatisch im Flash.

Aber das mit der Flash-Section hat er ja an sich hinbekommen, das
unterscheidet sich bei ihm nicht großartig von deinem Vorschlag.  Der
Dreh- und Angelpunkt war halt die linker section garbage collection.