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

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

Re: [avr-gcc-list] A fork in the road [Was: Linker script patch with __f


From: Erik Christiansen
Subject: Re: [avr-gcc-list] A fork in the road [Was: Linker script patch with __flashN size]
Date: Thu, 20 Dec 2012 13:12:56 +1100
User-agent: Mutt/1.5.20 (2009-06-14)

On 19.12.12 17:53, Weddington, Eric wrote:
> Hi Erik,
> 
> So far, I like how you're describing it below.
> 
> Did I miss the actual linker script that you're proposing? Do you have a 
> patch?
> 
> Eric

Oops, if I left it off, here it is, attached this time, since Johann
says it's easier to grab that than if I in-line it. (Some lists delete
attachments, so I wasn't game to begin with.)

Johann's test macros make it much quicker to test linker scripts, and
the test results (also attached) use them. (And that's where objdump -h
is a lot quicker for checking results, than shuffling through a big map
file.)

The new script architecture is standing up well to tests and
unanticipated challenges, like the .bootloader commandline stuff which
Johann has added to our tests. The approach is one I've successfully
used in industry for a couple of decades, facing all challenges, so we
should be able to make a good fist of handling all that the AVR needs.

I'll add __memx in a couple of weeks, as well as anything which crops up
in the interim. (I'm "heading bush" for Christmas, in a few minutes. The
car is loaded. So it might be safer to send the whole linker script,
just in case of patch difficulties at your end.)

Johann has mentioned that some users have let .progmem.data grow very
large. That would trigger the assertion we've added to warn us of
overflow of the lower 128 KiB (.lowtext). If I've picked up correctly on
Johann's concern, then it might be better to move .progmem.data* to the
start of .hightext? The script will still locate it in the same place if
there's no __flashN, and as low as practicable, if there is. And now
.progmem.data* can handle the legacy use case more robustly. Is that a
way to go?

Merry Christmas to all,

Erik

Attachment: avr6.x-new
Description: Text document

Attachment: script_tests
Description: Text document


reply via email to

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