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: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On > Behalf Of Erik Christiansen > Sent: Monday, December 17, 2012 4:38 AM > To: Georg-Johann Lay > Cc: avr-gcc-list@nongnu.org > 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 > AVR-GCC-list@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
