[avr-gcc-list] Re: internal error: out of range error (Erik Christiansen)

[Erik Christiansen]

On Wed, Sep 08, 2004 at 07:00:41AM +0300, Dafni & Robert Berger wrote:
> >Erik wote:
> >Wait, this is untried, but what about:
> >
> >const char  max7219_C_VER[] __attribute__ ((aligned (16), __progmem__))
> >= "@(#) $Id: max7219.c,v 0.0 2004/01/25 18:58:09Dafni Exp $";

Uurgh! Sorry, my cut/paste error. It should be "aligned(1)". Since
binutils use 2^n alignment notation for the avr, my oversight bumps
alignment to the next 64k boundary. (For some other targets, its
linear.)

> 
> F:/projects/undercvs/bergomat/src/max7219/max7219.c:82: warning: alignment
> of 'max7219_C_VER' is greater than maximum ob
> ject file alignment.  Using 1
> 
> And still the out of range error (I've been in this road before)

There's a clue here. If it's "Using 1" as claimed, then we should have
even byte alignment. Does objdump -D show odd alignment, confirming that
the error message has the cause we expect?

Alternatively, have you had a chance to try in-lining an asm ".align 1" ?
Just by clearing the error message, it would also confirm the cause.
(This might still be the easiest fix.)

OR, since .rel.rodata is not a convenient section, we could roll our
own, and place it _after_ all other .text in the flash image, so that
the whole problem goes away. In the linker script, after:

  .text :
  {
     __code_start = . ;

   ...

     _etext = . ;          /* Best to move this down to */
     __code_end = . ;
  }  > text

we add:

   .strings :
   {  *(.my_strings)
     _etext = . ;          /* here, in case it's used. */
   } > text

Then in the C code, this compiles OK:

const char  max7219_C_VER[] __attribute__
((section(".my_strings"),__progmem__)) =
"@(#) $Id: max7219.c,v 0.0 2004/01/25 18:58:09Dafni Exp $";

Running: avr-gcc -Wl,-verbose -Wl,--script=ld.lnk -o test2 test2.c
I see that avr-gcc is using the modified linker script, but
avr-objdump -h test2 shows:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000a90  00000000  00000000  00000094  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .strings      00000000  00000a90  00000a90  00000b3c  2**0
                  CONTENTS

So the section is generated, but not populated with the data provided.
It is also not "ALLOC, LOAD" either, so the linker would bypass it
anyway.

I'm afraid we're not there yet. I'll have another look at it tomorrow.
(Unless the in-line asm does the trick. ;-)

Erik