Re: A fork in the road [Was: Linker script patch with __flashN size]

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


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Erik Christiansen
> Sent: Monday, December 17, 2012 4:38 AM
> To: Georg-Johann Lay
> Cc: [email protected]
> Subject: [avr-gcc-list] A fork in the road [Was: Linker script patch with
> __flashN size]
> 
> On 17.12.12 15:01, Erik Christiansen wrote:
> > I'll outline the benefits of a more structured linker script, mirroring
> > the desired memory model, in another post.
> 
> As Johann is demonstrating, the old linker script architecture, burdened
> by a monolithic .text output section, not only does not explicitly
> describe the desired memory model of larger and more advanced AVR
> devices, but defeats his attempts to make it adequately locate the new
> memory spaces, and flow the remaining code without objectionable holes.
> (Amongst other problems.)
> 
> While we do not have a simple one-page statement of memory map
> requirements, those which have come to light recently, if read with one
> eye on the old linker script, show that we have four functional
> categories of flash memory:
> 
> The LOW TEXT, which must be below 128 KiB.
> Input sections: .vectors, .trampolines, .jumptables, .lowtext,
>                 .ctors, .dtors, .progmem.data
> 
> From zero to five __flashN pages, which must be 0x10000 page-aligned.
> Input sections: .progmem1.data*, .progmem2.data*, .progmem3.data*,
>                 .progmem4.data*, .progmem5.data*
> 
> The HIGH TEXT, which is .text that does not need to go below 128 KiB.
> It butts up to the last __flashN, or (in)to LOW TEXT, if no __flashN
> are used.
> Input sections: All the .initN, .text, all the .finiN, and anything else.
> 
> __memx: A compiler view which can be laid over more or less any flash
>         memory model, with RAM at 0x800000, maintaining compatibility
>         with the various binutils tools, and avrdude.
> 
> Because __flashN have fixed page addresses in the middle of the AVR
> flash memory map, the old monolithic .text output section is now best
> split into .lowtext and .hightext, as in the new script. That allows
> our code to open like a clamshell iff one or more __flashN are present.
> In the absence of any __flashN, lowtext and .hightext merge into a
> contiguous block of code. If .text is of modest size, then everything
> (including .text and .data) is packed into the first 128 KiB by the new
> script.¹
> 
> Assiduous readers of the thread thus far will be aware that the new
> linker script architecture thereby makes visible the avr6 functional
> memory model, giving users an immediate feel for how their code is
> fitting into the memory spaces they are using, whether explicitly via
> __flashN, or implicitly via all that is crammed into .lowtext by all its
> input sections. I.e. just run avr-objdump -h, for an instant radar map.
> 
> The new architecture also greatly simplifies correct location of the
> code in all the various use cases. In addition, it permits the use of
> ld's automatic overlap detection, and facilitates manual overflow
> detection, using assertions. The many failures Johann reports in his
> script attempt are largely due to using a venerable script architecture
> which has been obsoleted by the new AVR memory spaces supported in
> avr-gcc.
> 
> As running a test case, using Johann's test harness shows, a quick
> avr-objdump -h now gives us an instant clear view of where everything
> went, and how much overflow or overlap margin there is, well before
> trouble strikes, and we cop an error message.
> 
> It could hardly be easier or more transparent to use. Here are some
> simple use cases to get a feel for it. The first test case from my
> immediately prior post shows a nearly full lower 128 KiB (.lowtext):
> 
>       Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         00000000  00800200  0003f16e  0003f1e2  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   1 .lowtext      0001f10c  00000000  00000000  00000074  2**1
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .hightext     00020062  0001f10c  0001f10c  0001f180  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> The objdump confirms that the rest of text (.hightext) follows without
> one wasted byte. (There's one pad byte inside .hightext, if alignment is
> needed, obviously.)
> 
> If we use some __flashN, perhaps because we have had to shovel a great
> pile of .progmem.data* into .progmem2.data* and .progmem3.data, to pull
> .lowtext back under 128 KiB, then the tools can now show us exactly what
> is going on:
> 
> $ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
>   -DP0=0x1fe00 -DP2=0x10000 -DP3=0x87ff -DTEXT=0x20000 -mmcu=atmega2560 \
>   flash.sx
> 
>    Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         00000000  00800200  00058862  00058802  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   1 .lowtext      0001ff0c  00000000  00000000  00000094  2**1
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .flash2       00010000  00020000  00020000  0001ffa0  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .flash3       000087ff  00030000  00030000  0002ffa0  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .hightext     00020063  000387ff  000387ff  0003879f  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> We can see the margin at the 128 KiB limit:
> (.flash2 VMA) - (.lowtext size) - 0
>   00020000    -    0001ff0c          = 0xf4
> 
> We see that .flash2 is full, and .flash3 is about half full.
> We see that no space is wasted between .flash3 and the rest of our code
> in .hightext. Also, .data LMA immediately follows .hightext.
> 
> I.e. it is packed as tightly as the requirements allow.
> 
> If the boss asks "What's our memory situation? Can we add xxx features?",
> this one command gives an instant summary of the strengths and
> weaknesses of where we've stuffed things. If the full .lowtext is due to
> .trampolines and other unavoidable stuff, then we can't just say yes to
> lots more code.
> 
> Naturally, the "-j" arguments to avr-objcopy will differ a bit from
> those used with an ATtiny15, but any serious software developer uses a
> makefile target to produce the download file. After all, a manually
> entered command of that sort is far too unreliable to be used for
> software delivery.
> 
> Nevertheless, to handle a variety of .flashN output sections with a
> shorter and invariant objcopy command line, it might be more attractive
> to just use "-R .stab -R .stabstr", to let everything else through. That
> may be usable across a variety of AVRs, without modification. (Not
> tried, but "should just work".)
> 
> Anyway, I'm in the discussion until Wednesday, then incommunicado until
> mid to late January. Perhaps the choice of future path will have been
> mulled over by then.
> 
> My vote is to favour continued development of the tested successful
> script candidate over the repeated failures of the other. Its current
> effectiveness and resilience bodes well for unanticipated future
> enhancements. Any tweaking requests can be knocked over then. (There
> does not seem to be any hurry for any of this.)
> 
> Erik
> 
> ¹ $ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
>     -DTEXT=0x10000 -mmcu=atmega2560 flash.sx
> 
>    Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         00000000  00800200  00010146  000101ba  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   1 .lowtext      000000e4  00000000  00000000  00000074  2**1
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .hightext     00010062  000000e4  000000e4  00000158  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> Plainly, .lowtext, .hightext, and .data LMA all fit within 0x20000.
> Add stuff, and it expands as elegantly as can be desired, I think.
> 
> --
> (5)  It is always possible to agglutinate multiple separate problems
>      into a single complex interdependent solution. In most cases
>      this is a bad idea.                                    RFC-1925
> 
> _______________________________________________
> AVR-GCC-list mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________
AVR-GCC-list mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list