wie variablenadresse in einer eff datei ändern?

Klaus schrieb:
> Wenn ich eine Variable auf 0x0712 erwarte und im MAP File steht sie auf
> 0x81000712 oder so Ähnlich dann ist was für mich komisch.

Ist aber korrekt; die Binutils linearisieren lediglich den Adressraum. 
Im Linker Description File  für -mmcu=avr51 sieht das z.B. so aus:

1

MEMORY

2

{

3

  text   (rx)      : ORIGIN = 0,        LENGTH = __TEXT_REGION_LENGTH__

4

  data   (rw!x)    : ORIGIN = 0x800100, LENGTH = __DATA_REGION_LENGTH__

5

  eeprom (rw!x)    : ORIGIN = 0x810000, LENGTH = __EEPROM_REGION_LENGTH__

6

  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = __FUSE_REGION_LENGTH__

7

  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = __LOCK_REGION_LENGTH__

8

  signature (rw!x) : ORIGIN = 0x840000, LENGTH = __SIGNATURE_REGION_LENGTH__

9

  user_signatures (rw!x) : ORIGIN = 0x850000, LENGTH = __USER_SIGNATURE_REGION_LENGTH__

10

}

Die Ardesse ist also ungültig; vermutlich meinst du aber 0x810712, was 
eine Adresse im EEPROM darstellt.

Nop schrieb:
> Johann L. schrieb:
>> Die Ardesse ist also ungültig; vermutlich meinst du aber 0x810712, was
>> eine Adresse im EEPROM darstellt.
>
> Und dann haben wir da auch noch die Optimierung des GCC. Wenn eine
> Variable einen file-static scope hat und außer der Intialisierung in der
> Deklaration nur gelesen wird, dann ist GCC so schlau, das Ding in die
> readonly-Sektion zu verfrachten, um RAM zu sparen.

.rodata ist aber auch Teil des RAM.  Einfach mal ein Blick ins Linker 
Description File wagen.

Übrigens können file-static Variablen auch komplett wegoptimiert werden; 
ditto für andere Variablen im Static Storage, welche nur lesend 
zugegriffen werden.

> Das ist blöd, wenn man eine solche Variable aber im RAM haben will wegen
> der Zugriffszeit. Dann muß man GCC mit attributes anweisen, das Ding in
> die Data-Sektion zu packen.

Kommt auf die Architektur an; bei avr-gcc ist es nicht nötig.

Wenn man mit Zugriffszeiten jonglieren muss, dann hat das aber i.d.R. 
wenig mit RAM oder nicht-RAM zu tun, sondern eben mit den 
Zugriffszeiten.  Es gibt durchaus Architektiren, deren Data-Flash 
schneller zugreifbar ist als bestimmte RAM-Bereiche.  Und ja, wenn du 
das händisch zuordnen willst, dann wird's eine Schlacht mit 
Section-Attributen oder anderen Features wie #pragma.

> Merkwürdigerweise geht das aber dann nicht mehr zusammen mit dem
> const-Attribut,

const ist ein Qualifier, kein Attribut.  Und const in .data tut nicht 
weh; umgekehrt aber schon :-)

> weil GCC da aus unerfindlichen Gründen glaubt, const
> heiße "in die readonly-Sektion linken". Nichts dergleichen sagt der
> C-Standard, aber der GCC glaubt das halt.

Der C-Standard sagt nichts über's Binärformat, korrekt.  Das steht in 
der ABI, aber nicht im Standard, weil letzterer lediglich eine abstrakte 
Maschine beschreibt.  Ebensowenig wirst du im Standard finden, ob und in 
in welchen Registern Funktionsparameter zu übergeben sind und viele 
andere Sachen.

Die beste Section für readonly-Daten im Static Storage ist nun mal 
.rodata; und warum .rodata bei avr-gcc ins RAM lokatiert werden muss 
sollte evident sein.

Bei anderen Architekturen wird man .rodata natürlich ins Daten-Flash 
legen.

Klaus schrieb:
> Also ist das mit den komischen Adressen richtig.
> Aber warum sagt mit dann das AVRStudio immer das die Adresse nicht
> stimmt?
> Im Watch fenster steht so was wie "location not valid".

0x81000712 ist nun eben mal UNGÜLTIG.

Du musst also untersuchen, wer wo wann diese Adresse erzeugt.  Hilfreich 
ist z.B. ein Blick ins Map-File.

> Das der GCC hier was bei einem AVR sperren kann halte ich für äussert
> schwierig.

Hä?  Was soll der GCC "sperren" können?

Nop schrieb:
> Auf STM32 schmeißt (ARM-)GCC mir nämlich einen Error raus, wenn ich eine
> const-Variable per attribute nach Data legen will.

Ich bekomme für diesen Eins-fix-drei-Versuch lediglich eine Warnung
des Assemblers:

1

const int lut[] __attribute__((section(".data"))) = {1, 2, 4, 7, 14, 27, 51, 100};

2

int mumble = 42;

bringt:

1

% arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os -c foo.c

2

/tmp/ccAGlIhp.s: Assembler messages:

3

/tmp/ccAGlIhp.s:24: Warning: ignoring changed section attributes for .data

foo.o enthält aber die korrekten Daten, beide in .data:

1

% arm-none-eabi-objdump -ds foo.o

2

3

foo.o:     file format elf32-littlearm

4

5

Contents of section .data:

6

 0000 2a000000 01000000 02000000 04000000  *...............

7

 0010 07000000 0e000000 1b000000 33000000  ............3...

8

 0020 64000000                             d...            

9

Contents of section .comment:

10

 0000 00474343 3a202847 4e552054 6f6f6c73  .GCC: (GNU Tools

11

 0010 20666f72 2041524d 20456d62 65646465   for ARM Embedde

12

 0020 64205072 6f636573 736f7273 2920352e  d Processors) 5.

13

 0030 342e3120 32303136 30393139 20287265  4.1 20160919 (re

14

 0040 6c656173 6529205b 41524d2f 656d6265  lease) [ARM/embe

15

 0050 64646564 2d352d62 72616e63 68207265  dded-5-branch re

16

 0060 76697369 6f6e2032 34303439 365d00    vision 240496]. 

17

Contents of section .ARM.attributes:

18

 0000 41300000 00616561 62690001 26000000  A0...aeabi..&...

19

 0010 05436f72 7465782d 4d300006 0c074d09  .Cortex-M0....M.

20

 0020 01120414 01150117 03180119 011a011e  ................

21

 0030 04                                   .

Die Warnung kommt daher, dass "mumble" per .data-Pseudo-op
angelegt wird, lut[] dagegen per .section mit dem Attribut "a".
Keine Ahnung, welche Attribute sich hinter .data jetzt konkret
verbergen.

Jörg W. schrieb:
> Die Warnung kommt daher, dass "mumble" per .data-Pseudo-op
> angelegt wird, lut[] dagegen per .section mit dem Attribut "a".
> Keine Ahnung, welche Attribute sich hinter .data jetzt konkret
> verbergen.

Diese "Attribute" nennt ELF "Section Flags"; sie werden in den 
entsprechenden Section Headers gespeichert (im 3. Feld .sh_flags).

Problem ist wohl, dass mit dem Section Attribut keine Section Flags (und 
auch kein Alignment) angegeben werden können.  Flags für .data wären 
"aw".

Hier sollte aber helfen, eine eigene Input-Section zu nehmen wie 
.data.foo.  Geht's damit?

Klaus schrieb:
> @Johann L.
> Diese Adressen habe ich aus dem MAP File, wobei 0x81000712 falsch ist.
> Die Variable liegt logischerweise im Datenbereich:
> data   (rw!x)    : ORIGIN = 0x800100, LENGTH = __DATA_REGION_LENGTH__
> Bei 0x800712.

Und von wo bis wo hat das Device den RAM?

Evtl. läuft der RAM über, und die Tools machen ein wrap around beim 
Lokatieren bzw. die Hardware beim Zugriff.

Oder ein Problem mit dem Debugger selbst; dazu fällt mir nix ein weil 
ich keinen Degugger verwende.  Falls -gstrict-dwarf nicht hilft (eher 
wahrscheinlich) dann mal bei avrfreaks.net nachfragen, ist vermutlich 
ein bekanntes Problem dann.

Johann L. schrieb:
> dann mal bei avrfreaks.net nachfragen

Ich glaube, nach AVR Studio 4.18 muss man dort auch nicht mehr
fragen.  Das Ding ist einfach von vorgestern, und selbst wenn es
ein Bug ist (bei deren selbstgestricktem DWARF-Parser nicht so
unwahrscheinlich), wird ihn nach so vielen Jahren niemand mehr
reparieren.

Mit dem puren Offset 0x800000 sollte aber auch das olle Studio klar
kommen, den gab's schon seit eh und je.

Klaus schrieb:
> Aber nun einige Jahre und Versions updates später geht der selbe Code
> mit den selben Projekt Dateien nicht mehr.

Dann installier' dir doch mal ein aktuelles Atmel Studio.

Da must du bei der uralten Software halt mit Leben. Das Studio hatte 
schon damals zu seiner Blütezeit mit der aktuellsten WinAVR-Version 
diese Debuggerprobleme.

Immerhin kann du ja im Studio auch den Speicherinhalt direkt anschauen, 
da siehst du dann, was an der Adresse steht.

Oliver

Oliver S. schrieb:
> Immerhin kann du ja im Studio auch den Speicherinhalt direkt anschauen,
> da siehst du dann, was an der Adresse steht.

Was aber nicht der aktuelle Wert der Variablen sein muss, falls der 
grade in irgendwelchen Registern zu finden ist.

Kannst du denn die Komponente der Union angeben, die angezeigt werden 
soll?

Such dir einen noch viel älteren Compiler.

Wie ich schon schrieb, hat das Studio die Probleme mit WinAVR2010 schon 
immer. Der war damals schon "zu neu" dafür. Und daran hat sich in den 
letzten x Jahren nichts geändert.

Die ernsthafte Lösung ist natürlich, auf das aktuelle Studio und eine 
aktuelle toolchain umzusteigen. Früher war eben nicht alles besser.

Oliver