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:35 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> 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.
>

[hjl@gnu-cfl-2 pr25617]$ cat y.s
.data
bar:
.dc.a foo
[hjl@gnu-cfl-2 pr25617]$ gcc -c y.s
[hjl@gnu-cfl-2 pr25617]$ ./ld -shared y.o --hash-style=sysv
[hjl@gnu-cfl-2 pr25617]$ readelf -D -s  a.out

Symbol table for image:
  Num Buc:    Value          Size   Type   Bind Vis      Ndx Name
    1   0: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT UND foo
[hjl@gnu-cfl-2 pr25617]$ ./ld -shared y.o --hash-style=gnu
[hjl@gnu-cfl-2 pr25617]$ readelf -D -s  a.out
[hjl@gnu-cfl-2 pr25617]$

I will update my patch to not to generate such binary without section
header.

-- 
H.J.