Nios2 dynobj handling fixes

[Alan Modra]

On Tue, Feb 28, 2017 at 01:19:11PM +1030, Alan Modra wrote:
> A number of places in elf32-nios.c created dynamic sections but didn't
> set the hash table dynobj.  That meant we could have duplicate dynamic
> sections connected to a number of bfds, so size_dynamic_sections
> didn't properly discard or allocate contents.  All sorts of havoc
> ensued.

I've been going over just exactly what happened again.  The simple
hello world program had two each of dynamic .plt, .dynbss,
.data.rel.ro and their reloc sections.  One of each pair was
registered in the hash table shortcuts.  This actually wasn't due to
getting dynobj wrong in this case.  All of the sections were attached
to the crt1.o bfd.  However, the sections were not recognized by
size_dynamic_sections so they were not excluded.  In the case of
the dynamic .data.rel.ro it was the only .data.rel.ro section, and the
flags were wrong, in particular it was lacking SEC_LOAD.  *That* was
the reason why the empty .data.rel.ro output section had such an odd
file offset and why there was an extra PT_LOAD.

  [17] .dtors            PROGBITS        00003f20 000f20 000008 00  WA  0   0  4
  [18] .data.rel.ro      PROGBITS        00003f28 001f28 000000 00  WA  0   0  1
  [19] .dynamic          DYNAMIC         00003f28 000f28 0000d8 08  WA  5   0  4

We won't get the duplicate sections now due to removing the call to
nios2_elf32_create_dynamic_sections in nios2_elf32_check_relocs.  So
an empty .data.rel.ro now won't cause trouble.

But a non-empty dynamic .data.rel.ro without other .data.rel.ro
sections from object files might cause the odd section layout seen by
the nios2 testcase, I think.  This means that git commit afbf7e8e3
(https://sourceware.org/ml/binutils/2017-02/msg00380.html) wasn't just
cleanup.  I hadn't even spotted the missing SEC_LOAD when I made that
patch..  I'm putting that one on the branch too.

-- 
Alan Modra
Australia Development Lab, IBM