Add string representation of ELF e_flags for AVR.

binutils/ChangeLog:

	* readelf.c (decode_AVR_machine_flags): New function.
	(get_machine_flags): Add EM_AVR case.
AVR: Only set link-relax elf flag when appropriate.

The AVR target uses a bit in the elf header flags to indicate if the
object was assembled ready for linker relaxation.  Previously this flag
was always set, even when the object was not assembled ready for linker
relaxation.

This patch moves setting of the flag into the assembler, and sets it
only when the assembler is preparing the file for linker relaxation.

bfd/ChangeLog:

	* elf32-avr.c (bfd_elf_avr_final_write_processing): Don't set
	EF_AVR_LINKRELAX_PREPARED unconditionally.

gas/ChangeLog:

	* config/tc-avr.c: Add include for elf/avr.h.
	(avr_elf_final_processing): New function.
	* config/tc-avr.h (elf_tc_final_processing): Define.
	(avr_elf_final_processing): Declare

gas/testsuite/ChangeLog:

	* gas/avr/link-relax-elf-flag-clear.d: New file.
	* gas/avr/link-relax-elf-flag-set.d: New file.
	* gas/avr/link-relax-elf-flag.s: New file.
AVR/ld: Propagate link-relax elf header flag correctly.

The AVR target has an elf header flag to indicate if an object was
assembler ready for linker relaxation.  If a partial link is performed
then it is important that the link-relax flag in the output object is
set correctly, otherwise, during the final link, we might try to perform
linker relaxation on code that was not assembled suitably.

As the link-relax elf header covers the entire object file we must be
conservative when setting the flag in the output object, so, for a
partial link, any input object that does not have the link-relax flag
set will cause the output object to also not have the link-relax flag
set.

This conservative approach could be softened in future, we only need to
disable the link relax flag if an input file is not marked link-relax
ready, and the input file contains a relaxable section.  However, I've
left this optimisation for a later day.

For the final link I've overloaded the use of the link-relax elf header
flag, in a final executable, the flag now indicates if the executable
was built with linker relaxation on or not.

ld/ChangeLog:

	* emultempl/avrelf.em: Add include of elf/avr.h.
	(avr_finish): New function.
	(LDEMUL_FINISH): Added.

ld/testsuite/ChangeLog:

	* ld-avr/relax-elf-flags-01.d: New file.
	* ld-avr/relax-elf-flags-02.d: New file.
	* ld-avr/relax-elf-flags-03.d: New file.
	* ld-avr/relax-elf-flags-04.d: New file.
	* ld-avr/relax-elf-flags-05.d: New file.
	* ld-avr/relax-elf-flags-06.d: New file.
	* ld-avr/relax-elf-flags-07.d: New file.
	* ld-avr/relax-elf-flags-08.d: New file.
	* ld-avr/relax-elf-flags-a.s: New file.
	* ld-avr/relax-elf-flags-b.s: New file.
Only allocatable code sections are relaxable.

This change is not critical, but is I believe correct.  Only allocatable
code sections will be relaxed (seebfd/elf32-avr.c:elf32_avr_relax_section).
This will be more use later as it will reduce the number of property
records that are emitted in order to support .org and .align directives.

gas/ChangeLog:

	* config/tc-avr.c (relaxable_section): Only allocatable code
	sections are relaxable.
gas: Initial support for .org / .align with linker relaxation.

This is a prototype for supporting .org and .align for AVR with linker
relaxation.  The first step is collecting information in the assembler
and packaging it up to pass to the linker.

This patch tries to do this collection of information, and writes out
the data into a support section ready for the linker to consume.

This work is not complete, and requires more development, cleanup, and
testing.
objdump: Add support for printing out .avr.prop.

This adds a hook for dumping the contents of .avr.prop in a structured
way.
First stage of using directive data.

Reads the data in an associates it with the section to which the data
applies.  Still no use is currently made of the data.
Make use of directive data.

This uses the .org and .align directive data to ensure that these
directives are left in place.
This is the simplest use of this data to achieve a correct result.  We
can do better in the case of alignment, but in order to achieve this
we'll need to gather all the deletions together and execute them in one
go.  This will require further reworking.