Apologies for this post linking to the thread only by subject - the maillist archive does not appear to contain references which would allow this post to link solidly. (I've only subscribed a few minutes ago.)
On: Mon, 07 Jan 2013 20:59:03 +0100, Georg-Johann Lay wrote: (In http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00346.html ) > This is a tentative patch that adds symbols that can be used as > predicates in the linker script. I'm sorry, but the patch is entirely unnecessary, since a linker script exists which achieves all the essential goals of this patch, without attempting to bury linking functionality in the compiler. [4] It is, IME, not a good idea to embed linker behaviour in the compiler. Doing so would lead to brittleness in avr-gcc, as future options become constrained by poor past decisions. Maintainability of avr-gcc also suffers. It is no accident that PR14406 is against binutils. That is where section location needs to be enhanced. Sorry, but that is not compiler functionality. > Background is binutils PR14406: Data in address space __flash1 must be located > in such a way that the high byte (hh8) of the address is 0x1. This is needed > because avr-gcc sets RAMPZ to 0x1 before reading data from __flash1. > The input section for __flash1 is .progmem1.data > Similar for other __flash<N>, n = 2..5 > The problems to be solved are: > 1) .progmem<N>.data must be located in [0x<N>0000, 0x<N>ffff]. > 2) If there is too much data in .progmem<N>.data the linker should complain. > 3) Moving the location counter to 0x<N>0000 is only needed if > .progmem<N> is non-empty. > 4) We must be careful not to move to pointer backwards. > 5) User-level build-scripts and Makefiles should be the same if > the user does not use the new features like __flash<N>. > Even if __flash<N> is used, it's appreciated if everything > works out of the box and without changing calls of objcopy, > for example. > 6) If .text extends to, say, 0x20010, it's still fine if .progmem2.data > starts at 0x20011. There is no need to throw an error because text > overlaps 0x20000...0x2ffff. > The very problem is that the linker script language is too limited. Neither > does it support memory holes, nor can a section float around others, and not > even detecting if a section does not contain any data works as promised by > binutils, cf. [1]. I'm sorry, but that is only mistaken belief. The language is largely sufficient for competent scripters - to the extent that the linker script in [1a] (follow-up to [1]) does support memory holes, and does float sections around others, as well as "detecting if a section does not contain any data". (It opens up .lowtext and .hightext like a clamshell, to insert any populated __flash<N> sections, then closes the clamshell about the whole, to avoid wasting memory.) If there is any doubt, then please run the testcases, also included in [1a]. (Or at least read the included "avr-objdump -h" outputs which show the results.) They confirm automatic opening of holes, for insertion of the __flash<N> sections, with automatic butting up, to conserve memory. These have been published on binutils and avr-gcc maillists since last year, without technical challenge. Please try all the test cases. (They use Georg-Johann's nifty test macros.) > The patch addresses the latter problem: It defines symbols that can be used > like predicates by the linker script like so, cf. [2]: > .text : > { > ... > . = MAX (DEFINED(__need_.progmem1.data) ? 1 << 16 : 0, ABSOLUTE(.)) ; > __progmem1_start = . ; > *(.progmem1) > *(.progmem1.*) > __progmem1_end = . ; > ... > } > text A competent linker script does not need crutches embedded in the compiler. The script in [1a] allows ld to do the linking and location unaided by hacks in avr-gcc. (If anything needs tweaking, please show a testcase.) > There was some discussion in [3] about how PR14406 could be approached and > there were basically two proposals: > - One from Erik that does not solve > 3), Sorry, that is false. The published test results demonstrate that the competent linker script does move the location counter to 0x<N>0000 only if __flash<N> is non-empty. Please _try_ the relevant published testcases. E.g. the last testcase in [4] shows that ".hightext) snugs down [to .lowtext] if there are no __flashN" i.e. empty __flash<N> are fully handled. > 6) Ahem, that is also false. The published test results also demonstrate that the competent linker script does not "throw an error because text overlaps 0x20000...0x2fff". The last testcase in [4] shows text (in .hightext) running from 0000010c to 0002016e, without any hassles. > or 5) But I am forced to agree that those not using the avr6 architecture should not be inconvenienced at all. Those who decide to do so should only encounter a small upgrade learning curve, and it should make logical sense, so that the cost/performance gains are obvious and very attractive. It is only recently that I have outlined, on avr-gcc ML, how easy it is to leave most users happily oblivious to the enhancements to avr6. I.e. users of lower cpu architectures would not be exposed to the enhanced linker script, so cannot be affected by it. ;-) > i.e. requires a change in the user Makefiles like -j .hightext > instead of -j .text etc. .text is after .progmem<N> Well, embedded systems programmers usually have to rewrite or at least tweak the makefile for each new project. A trivial variation in avr-objcopy parameters is less than a non-issue in that context, I submit. It is not as if we're adding a new command to run. We will supply makefile examples for the user's convenience. > - One from me with the predicate-like-symbols kludge that needs a > GCC change and has less informative error messages than Erik's > approach in the case anything overflows. > .text is before .progmem<N> It's clear by now that IME a completely unnecessary linker-behaviour kludge should not be inflicted on avr-gcc. Given that the self-sufficient linker script also has more informative error messages, then there seems to be no reason to proceed with the kludge. > Maybe everything can be solved much easier and I am lacking the respective > binutils knowledge... Johann, it has taken many years to accumulate the skills and confidence to whack on the head any linker script challenges I've had to solve so far. I remember what it was like when it seemed that the language was "limited", but now I realise that it was only experience which was lacking. It is easier than fixing gcc bugs, but that does not mean that it can be learned overnight. The documentation is quite a good reference once you're familiar with ld, but I found that great persistence and much experiential learning was required at the bottom of the learning curve. > Thoughts? Cooperation has great advantages. Targeting our efforts in the areas where we have strongest skills will maximise our effectiveness. Let's see what Eric Weddington says after he's tried out the new linker script, possibly with additional test cases. The new script is more powerful and flexible than the old. It should be fairly easy to add the afterthoughts which are sure to crop up now that the basics are done. If he's happy, I'll implement the binutils tweak to employ one script template for lower avr architectures, and another for avr6. Fortunately, Makefile.in is already set up to handle that, so there's not a lot of work for me to do. In parallel, we can discuss what's needed for __memx. It would be good to have thoughts from userland, but we can start without. (In the absence of prior thoughts, I'll post on avr-gcc re that in the next day or two.) Erik > [1] http://sourceware.org/ml/binutils/2012-12/msg00151.html [1a] http://sourceware.org/ml/binutils/2012-12/msg00152.html > [2] http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00046.html > [3] http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00029.html [4] http://www.mail-archive.com/avr-gcc-list@nongnu.org/msg08215.html -- All I kin say is when you finds yo'self wanderin' in a peach orchard, ya don't go lookin' for rutabagas. - Kingfish
