bfd cleanups

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
>> @@ -8187,47 +8092,6 @@ _bfd_mips_elf_final_link (bfd *abfd, str
>>  		     - g->global_gotsym->dynindx)
>>  		    <= g->global_gotno);
>>      }
>> -
>> -#if 0
>> -  /* We want to set the GP value for ld -r.  */
>> -  /* On IRIX5, we omit the .options section.  On IRIX6, however, we
>> -     include it, even though we don't process it quite right.  (Some
>> -     entries are supposed to be merged.)  Empirically, we seem to be
>> -     better off including it then not.  */
>> -  if (IRIX_COMPAT (abfd) == ict_irix5 || IRIX_COMPAT (abfd) == ict_none)
>> -    for (secpp = &abfd->sections; *secpp != NULL; secpp = &(*secpp)->next)
>> -      {
>> -	if (strcmp ((*secpp)->name, MIPS_ELF_OPTIONS_SECTION_NAME (abfd)) == 0)
>> -	  {
>> -	    for (p = (*secpp)->link_order_head; p != NULL; p = p->next)
>> -	      if (p->type == bfd_indirect_link_order)
>> -		p->u.indirect.section->flags &= ~SEC_HAS_CONTENTS;
>> -	    (*secpp)->link_order_head = NULL;
>> -	    bfd_section_list_remove (abfd, secpp);
>> -	    --abfd->section_count;
>> -
>> -	    break;
>> -	  }
>> -      }
>> -
>> -  /* We include .MIPS.options, even though we don't process it quite right.
>> -     (Some entries are supposed to be merged.)  At IRIX6 empirically we seem
>> -     to be better off including it than not.  */
>> -  for (secpp = &abfd->sections; *secpp != NULL; secpp = &(*secpp)->next)
>> -    {
>> -      if (strcmp ((*secpp)->name, ".MIPS.options") == 0)
>> -	{
>> -	  for (p = (*secpp)->link_order_head; p != NULL; p = p->next)
>> -	    if (p->type == bfd_indirect_link_order)
>> -	      p->u.indirect.section->flags &=~ SEC_HAS_CONTENTS;
>> -	  (*secpp)->link_order_head = NULL;
>> -	  bfd_section_list_remove (abfd, secpp);
>> -	  --abfd->section_count;
>> -
>> -	  break;
>> -	}
>> -    }
>> -#endif
>
> Richard, is this code obsolete for IRIX?

Well, PT_MIPS_REGINFO is supposed to be mandatory in 32-bit objects
and DT_MIPS_OPTIONS is mandatory in NewABI objects, so I can see why
the status quo makes sense for IRIX.  I certainly don't know of any
reason why we'd want to re-enable the code.

The comment for the first hunk claims that we don't merge .reginfo
correctly, but I think we try to do that in _bfd_mips_elf_final_link,
so maybe it's simply out of date.  I think that bit can probably go.

On the other hand, I suppose the second hunk is one of those cases where
the #if 0'd code is acting as commentary.  "We don't merge .MIPS.options
sections correctly, but it doesn't seem to matter, and we've decided to
keep the section anyway."  (Note that the comment is saying what we
do now, not what would happen if we re-enable the code.)  No opinion
either way on whether it's worth keeping.

Richard