Re: RFC: [PATCH] ELF: Don't require section header on ELF objects

["H.J. Lu" <hjl.tools@gmail.com>]

On Sun, Mar 8, 2020 at 7:23 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Mon, Mar 09, 2020 at 12:29:48PM +1030, Kaylee Blake wrote:
> > On 9/3/20 12:06 pm, H.J. Lu wrote:
> > > On Sun, Mar 8, 2020 at 5:05 PM Alan Modra <amodra@gmail.com> wrote:
> > >> Well we certainly don't do such sorting.  For example, from a freshly
> > >> build ld/ld-new --enable-targets=all
> > >>
> > >>    148: 0000000000f08380     4 OBJECT  GLOBAL DEFAULT   25 opterr@GLIBC_2.2.5 (3)
> > >>    149: 0000000000402f80     0 FUNC    GLOBAL DEFAULT  UND calloc@GLIBC_2.2.5 (3)
> > >>    150: 0000000000881536    35 FUNC    GLOBAL DEFAULT   13 _obstack_allocated_p
> > >>
> > >
> > > I will make 2 changes:
> > >
> > > 1.  Update -z nosectionheader to guarantee that the last entry in
> > > dynamic symbol table
> > > is defined.
> > > 2.  Update --remove-section-header to issue an error if the last entry
> > > in dynamic symbol
> > > table is undefined.
> > >
> >
> > With some testing, it seems like ld will emit an ordered symbol table
> > iff it's using the DT_GNU_HASH hash table style
>
> It doesn't.  The snippet of .dynsym I posted was from a binary with
> DT_GNU_HASH.  elflink.c:_bfd_elf_link_renumber_dynsyms should convince
> you that any ordering seen is by chance.
>
> >, and my understanding is
> > that DT_GNU_HASH in fact requires this behaviour.
>
> Apparently not.  ;-)
>
> > So in that case, we
> > don't need to do an additional check, because we only need the ordering
> > if we are looking up through DT_GNU_HASH instead of DT_HASH.
> >
> > --
> > Kaylee Blake <klkblake@gmail.com>
> > C is the worst language, except for all the others.
>

x86 backend does:

 if (!local_undefweak
      && !h->def_regular
      && (h->plt.offset != (bfd_vma) -1
          || eh->plt_got.offset != (bfd_vma) -1))
    {
      /* Mark the symbol as undefined, rather than as defined in
         the .plt section.  Leave the value if there were any
         relocations where pointer equality matters (this is a clue
         for the dynamic linker, to make function pointer
         comparisons work between an application and shared
         library), otherwise set it to zero.  If a function is only
         called from a binary, there is no need to slow down
         shared libraries because of that.  */
      sym->st_shndx = SHN_UNDEF;
      if (!h->pointer_equality_needed)
        sym->st_value = 0;
    }

Entries in DT_GNU_HASH were originally defined.  A backend
may change some entries to undefined.  I think my patch is OK.

-- 
H.J.