AVR-gcc: strukturen mit Funktions-pointern im progmem liefert falsche pointer

[Martin S. (msperl)]

Hallo!

Habe da einen seltsamen "Effekt" bei meinem neuen Projekt:

Der folgende Code-schnipsel:

void loop4ever(uint16_t *t);
typedef struct test {
        void (*init)(uint16_t* t);
} test_t;
const test_t mytest __attribute__((progmem)) __attribute__((aligned (8))) = {
        .init=&loop4ever,
};
void loop4ever(uint16_t *t) { while(1) { t++;} }

produziert im gedumpten elf (avr-objdump -Dz main.elf):

...
00000088 <mytest>:
  88:   a6 00           .word   0x00a6  ; ????
  8a:   00 00           nop
  8c:   00 00           nop
  8e:   00 00           nop
...
0000014c <loop4ever>:
 14c:   ff cf           rjmp    .-2             ; 0x14c <loop4ever>

man sieht, daß der Pointer in mytest eindeutig an eine falsche Adresse 
zeigt (0x00a6 und nicht an 0x014c) - und ja, ich sehe es auch wenn ich 
mir die Adresse von meinem Code auf USART ausgeben lasse...

Sitze ich da einem compiler/linker bug auf?
Denn IMO sollte der code eigentlich ja korrekte Pointer produzieren...

Hat jemand schon ein ähnliches Problem gehabt und auch vielleicht auch 
gelöst?

Danke,
        Martin

P.s: und das nicht funktionierende Alignment in C mit progmem sei hier 
nur eine Randnotiz

P.s: der avr-gcc ist 4.7.0

[Markus M. (adrock)]

...auffällig ist, dass 0xa6 die Hälfte von 0x14c ist.

Das könte seine Richtigkeit haben, da der Programmcode in WORTEN 
adressiert wird. D.h. die "echte" Adresse ist der Ptr * 2.

Grüße
Markus

[Martin Beuttenmüller (Gast)]

@Markus
Wow, genial erkannt ...
Ich hätte auch erst "den Wald gerodet, um den Baum zu finden"!  ;-}

Danke !
Martin

[Martin S. (msperl)]

Danke - das half!

[Johann L. (gjlayde)]

Martin Sperl schrieb:
> Hallo!
>
> Der folgende Code-schnipsel:
>
> void loop4ever(uint16_t *t);
> typedef struct test {
>         void (*init)(uint16_t* t);
> } test_t;
> const test_t mytest __attribute__((progmem)) __attribute__((aligned
> (8))) = {
>         .init=&loop4ever,
> };
> void loop4ever(uint16_t *t) { while(1) { t++;} }

Tu dir einen Gefallen und formatiere den Code :-)

> P.s: und das nicht funktionierende Alignment in C mit progmem sei hier
> nur eine Randnotiz

Wieso? mytest ist doch auf 8 Bytes aligned?

> P.s: der avr-gcc ist 4.7.0

Nicht wirklich empfohlen, insbesondere wenn du Xmega oder Devices mit 
8-Bit SP verwendest.  Immer die Release Notes lesen!!!

http://gcc.gnu.org/gcc-4.7/changes.html

Seit mehreren Monaten gibt es avr-gcc 4.7.2.

Mit 4.7 brauchst du auch kein progmem mehr.  Wenn mytest im Flash liegt 
willst du wahrscheinlich auch irgendwann drauf zugreifen?

#include <stdint.h>

typedef struct 
{
    void (*init)(uint16_t*);
} test_t;

static void loop4ever (uint16_t *t)
{
    (void) t;
    while(1);
}

const __flash test_t mytest __attribute__((aligned(8))) =
{
    .init = loop4ever
};

void runtest (const __flash test_t *t, uint16_t *val)
{
    t->init (val);
    mytest.init (0);
}

 
Das ergibt:
 

loop4ever:
.L2:
  rjmp .L2

runtest:
  movw r30,r24
  lpm r0,Z+
  lpm r31,Z
  mov r30,r0
  movw r24,r22
  icall
.L4:
  rjmp .L4

.global  mytest
  .section  .progmem.data,"a",@progbits
  .p2align  3
  .type  mytest, @object
  .size  mytest, 2
mytest:
  .word  gs(loop4ever)
  .ident  "GCC: (GNU) 4.7.2"

 
Wie man sieht ist da auch das gewünschte .p2align 3.

[Martin S. (msperl)]

Auf das mit dem align bin ich auch gekommen, daß es geht - bin über den 
Unterschied im align parameter zwischen gas und gcc gestolpert...

Das update mit dem Compiler ist nett - ich mache mich einmal auf die 
Suche nach neuen deb gcc-avr Paketen für den RPI... (updates dafür gibt 
es leider nicht im "Standard"...)

Danke nochmals allen Helfern!
Martin