avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Providing a vacant_flash address, even if .eeprom default


From: Erik Christiansen
Subject: [avr-gcc-list] Providing a vacant_flash address, even if .eeprom defaults go into flash.
Date: Sat, 1 May 2010 17:22:18 +1000
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

On Fri, Apr 30, 2010 at 07:23:55AM -0700, Dave Hylands wrote:
> On Fri, Apr 30, 2010 at 1:34 AM, Erik Christiansen wrote:
> ...snip...
> 
> >   __vacant_flash = DEFINED (__eeprom_in_flash) ? __data_load_end +
> >                    SIZEOF(.eeprom) : __data_load_end ;
> >
> >   /* ld should't care whether it's one line or wrapped. */
> >
> >
> > Now there will by default be no wasted flash bytes, because
> > __vacant_flash = __data_load_end , but when we use on the commandline:
> >
> > ld --defsym __eeprom_in_flash=1    # Or in gcc-friendly syntax:
> >
> > avr-gcc ... -D eeprom_in_flash
> 
> Actually, I'm pretty sure this last one won't work. -D defines a
> pre-processor symbol. I think you'd need to use something like
> 
> avr-gcc ... -Wl,--defsym,__eeprom_in_flash=1

Yes, You're dead right. Precisely that feeds my first suggestion through
gcc, and (unsurprisingly) works just as well as the direct invocation of
ld.

And Oh-oh, using gcc's "-D" isn't working for me either, in this
context. Perhaps I have only used that syntax for #ifdef in individual
compile units, after all.

> > then our linker script will obediently shuffle __vacant_flash up to make
> > room for .eeprom.
> >
> > Will that do?
> 
> That looks to be generic enough to be useful.

And (a little belatedly) it's confirmed to work, with the --defsym
commandline syntax.

Thanks for the expert critique.  :-)

Erik

-- 
A computer is like an air conditioner, it works poorly when you open Windows.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]