Re: Multiple sections with the same name again

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, May 20, 2004 at 01:39:54PM -0700, H. J. Lu wrote:
> While working on the merge section bug, I noticed that _bfd_merge_section
> does
> 
>   for (sinfo = (struct sec_merge_info *) *psinfo; sinfo; sinfo = sinfo->next)
> if ((secinfo = sinfo->chain)
>         && ! ((secinfo->sec->flags ^ sec->flags) & (SEC_MERGE | SEC_STRINGS))
>         && secinfo->sec->entsize == sec->entsize         && ! strcmp
> (secinfo->sec->name, sec->name))
>       break;
> 
> It won't work right with multiple sections with the same name. There
> may be more places like that. What is the best way to make sure we
> catch and fix all of them? I am thinking to add a new bfd target
> function, match_section_signature, and change "name" to "foobar"
> temporarily. Replace all strcmp (sec1->name, sec2->name) with
> bfd_match_section_signature (sec1, sec2) and change "foobar" back to
> "name".

This piece of code looks like it is just looking for a "struct
sec_merge_info" for a given section.  However, on looking closer, I see
that it is really looking for the right group of sections.  ie. sections
that have the same SEC_MERGE attribute and entity size that will map to
the same output section.  Jakub assumes that all input sections with a
particular name will map to the same output section, which isn't always
the case as custom linker scripts can arbitrarily map input sections.

So I think there is a more fundamental design problem here.  The merge
code shouldn't be trying to guess what the linker will do in
ldlang.c:map_input_to_output_sections.  There's a comment in ldlang.c
lang_process before the bfd_merge_sections call that says in part:

     This has to be done after GC of sections,
     so that GCed sections are not merged, but before assigning output
     sections, since removing whole input sections is hard then.

That's not strictly true, as it isn't so hard to remove output sections
after map_input_to_output_sections.  For example, many of the backend
size_dynamic_section routines remove sections.  Where it becomes truly
hard is after the lang_process -> ldemul_before_allocate ->
bfd_elf_size_dynamic_sections -> _bfd_elf_link_renumber_dynsyms call and
dynamic symbols have been sized.

I think what should be done is
- Remove the _bfd_merge_section call in elf_link_add_object_symbols.
  This is primarily collecting information on what sections should be
  merged.
- Move the bfd_merge_sections call in lang_process after
  lang_place_orphans and before ldemul_before_allocation.
- Traverse the linker script in bfd_merge_sections to determine which
  sections should be merged.

Jakub, do you see any problem in doing things this way?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre