[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [avr-gcc-list] Providing a vacant_flash address, even if .eeprom defaults go into flash.,
Erik Christiansen <=