Re: How to reclaim .rela.dyn entries for symbols that become hidden?

[Carlos O'Donell <carlos at systemhalted dot org>]

On Mon, Jul 04, 2005 at 11:43:32AM -0400, Daniel Jacobowitz wrote:
> > I'm still stuck. At the point in allocate_dynrelocs the undefined
> > symbol is not marked dynamic, or hidden for matter. I am forced to
> > allocate space.
> 
> How are symbols becoming hidden after allocate_dynrelocs?  Where does
> it happen?

I'm trying to track them down.

In allocate_dynrelocs I see them like this:

2178: (allocate_dynrelocs): Dumping symbol
397: (DBG_DUMP): Dumping...
        info->shared 0
        sym __init_array_start
        hh 0x206798
        hh->non_plabel_ref  0
        hh->plabel 0
        hh->eh.dynindx  0xffffffff
        hh->eh.non_got_ref 0
        hh->eh.def_dynamic 0
        hh->eh.def_regular 0
        hh->eh.root.type == bfd_link_hash_undefined 1
        hh->eh.root.type == bfd_link_hash_undefweak 0
        ELF_ST_VISIBILITY (hh->eh.other) == STV_DEFAULT 1
        SYMBOL_CALLS_LOCAL (info, &hh->eh) 0
2204: (allocate_dynrelocs): Record dynamic symbol __init_array_start

Code in allocate_dynrelocs to accounts for them:

      /* Make sure this symbol is output as a dynamic symbol.
         Undefined weak syms won't yet be marked as dynamic.  */
      if (eh->dynindx == -1
          && !eh->forced_local
          && eh->type != STT_PARISC_MILLI)
        {
          if (! bfd_elf_link_record_dynamic_symbol (info, eh))
            return FALSE;
        }

After record dynamic symbol, it has a dynindx, and the code allocates
space in the srelgot section.

In the executable they appear in the .dynsyms but their visibility is
hidden, and since they are also local the code does a bfd_put_32 to
fixup the relocation, and the reloc space is left unused.

In relocate_section they appear like this:

3966: (elf32_hppa_relocate_section): Dumping r_type 34
397: (DBG_DUMP): Dumping...
        info->shared 0
        sym __init_array_start
        hh 0x206798
        hh->non_plabel_ref  0
        hh->plabel 0
        hh->eh.dynindx  0x7
        hh->eh.non_got_ref 0
        hh->eh.def_dynamic 0
        hh->eh.def_regular 1
        hh->eh.root.type == bfd_link_hash_undefined 0
        hh->eh.root.type == bfd_link_hash_undefweak 0
        ELF_ST_VISIBILITY (hh->eh.other) == STV_DEFAULT 0
        SYMBOL_CALLS_LOCAL (info, &hh->eh) 1
4004: (elf32_hppa_relocate_section): do_got = 1;
4056: (elf32_hppa_relocate_section): bfd_put_32

It's not my job to set the visibility, or to remove the undefined-edness
of the symbol, that's done by the linker. I should probably test this on
i386 to see how the symbol looks to the backend during
allocate_dynrelocs.

I expected that a change in visibility would have called
elf_backend_hide_symbol, but that doesn't seem to be the case for these
symbols.

> > Now the question I don't clearly understand is: After having
> > allocated that space, can I go back and change the section size in
> > relocate_section, like this:
> > 
> >       sec = htab->sgot;
> >       sec->size -= GOT_ENTRY_SIZE;
> 
> No.  We've fixed file offsets after allocation.

I figured as much. I was hoping that the size variables would be used in
the last phase during the object writeout.
 
> > Second question: Where do __init_array_start, __init_array_end,
> > __fini_array_start, and __fini_array_end resolve to?
> > 
> > Are these provided by the linker's internal script?
> 
> ld/emultempl/elf32.em:
>       gld${EMULATION_NAME}_provide_bound_symbols (".init_array",
>                                                   "__init_array_start",
>                                                   "__init_array_end");

Ah, perfect, I missed that. Thanks Daniel.

c.