Georg-Johann Lay <a...@gjlay.de> writes: > On 05.07.2017 10:17, Georg-Johann Lay wrote: >> On 04.07.2017 20:11, Richard Sandiford wrote: >>> Georg-Johann Lay <a...@gjlay.de> writes: >>>> Hi, >>>> >>>> This patch adds support for devices that can access flash memory >>>> by LD* instructions, hence there is no need to put .rodata in RAM. >>>> >>>> The default linker script for the new multilib versions already >>>> supports this feature, it's similar to avrtiny, cf. >>>> >>>> https://sourceware.org/PR21472 >>>> >>>> This patch does the following: >>>> >>>> * Add multilib variants avrxmega3 and avrxmega3/short-calls. >>>> >>>> * Add new option -mshort-calls for multilib selection between >>>> devices with <= 8KiB flash and > 8KiB flash. >>>> >>>> * Add specs handling for -mshort-calls: The compiler knows >>>> if this option is needed or not appropriate (similar to -msp8). >>>> >>>> * Add new ISA feature AVR_ISA_RCALL for multilib selection >>>> via -mshort-calls. >>>> >>>> * Add a new row to architecture description that contains the >>>> start address of flash memory in the RAM address range. >>>> (The actual value is not needed). >>>> >>>> * For devices with flash in RAM space, don't let .rodata >>>> objects trigger need for __do_copy_data. >>>> >>>> * Add some devices. >>>> >>>> * Add configure test for Binutils PR21472. >>> >>> Sorry if this has already been discussed, but it's useful to be >>> able to do things like: >>> >>> .../configure --target=avr-elf --with-cpu=arc700 >>> make -j... all-gcc >>> >>> as a basic sanity test of a pan-target patch. (I usually do >>> before-and-after assembly comparisons too if no changes are >>> expected.) The way the configure test is written means that >>> it's no longer possible to do this without first building a >>> trunk version of binutils for avr-elf. >>> >>> Thanks, >>> Richard >> >> Okay, I already thought of a less aggressive approach, I'll >> try to address it soon. > > Is the following addendum in order? > > The avr maintainers appear to be offline since several weeks already, > maybe a global maintainer can have a look and approve it for trunk?
Thanks for doing this. LGTM (though obviously I can't approve) Richard
