Re: [avr-gcc-list] prog_mem limitation?

[hutchinsonandy]

As I now see we do have a warning, this is not a bug.




-----Original Message-----
From: Mark Litwack <address@hidden>
To: Weddington, Eric <address@hidden>
Cc: address@hidden
Sent: Tue, 13 May 2008 12:50 pm
Subject: Re: [avr-gcc-list] prog_mem limitation?



On Tuesday 13 May 2008 11:45:53 am Weddington, Eric wrote:
> > -----Original Message-----
> > From:
> > address@hidden
> > [mailto:address@hidden
> > org] On Behalf Of Mark Litwack
> > Sent: Tuesday, May 13, 2008 6:48 AM
> > To: address@hidden
> > Subject: Re: [avr-gcc-list] prog_mem limitation?
> >
> > On Tuesday 13 May 2008 05:36:25 am Marc Wetzel wrote:
> > > Hi,
> > >
> > > I just found out the hard way, that the allocation of
> >
> > prog_mem variables
> >
> > > is not location independend.
> > >
> > > So, if you alloc a variable outside of a function, e.g. in the
> > > "standard" top area of your c-file, everything is working
> >
> > as expected.
> >
> > > But if you declare it inside a function, it does not work
> >
> > (as expected).
> >
> > > Working Example:
> > > --
> > > const prog_mem char teststring[]= "Teststring";
> > >
> > > void * test(void) {
> > >     fprintf_P(uart, teststring);
> > > }
> > > --
> > >
> > > Non-Working Example (but compiling fine):
> > > --
> > > void * test(void) {
> > >     const prog_mem char teststring[]= "Teststring";
> > >     fprintf_P(uart, teststring);
> > > }
> > > --
> > >
> > > Is this the intended behaviour?
> > > What cause is here the trigger?
> >
> > I'm not eaxctly sure why they behave differently, but the
> > latter causes teststring[] to be allocated in the .data
> > section instead of .progmem.
>
> Probably because the second case does not have the 'static' keyword?
>
> Eric

Hmm...  Yes, supplying static does work.  I guess it makes
sense, but the intended storage class is somewhat nebulous
in the non-'static' case.

Indeed, the compiler spit out a warning on the non-'static'
case:

  main.c: In function 'test':
  main.c:294:warning: '__progmem__' attribute ignored

which whipped by and I missed it before.  Whether this case
is deserving of an error is arguable since any context the
variable would be used in would be wrong, but at least gcc
knew something was amiss.

-mark


_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list