[patch,avr] Add support for devices with flash accessible by LD.

[Richard Sandiford]

Georg-Johann Lay <avr@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 <avr@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