public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* Re: Making DT_HASH optional?
       [not found] ` <CAJimCsEOsEe8=T8s9sSCw5wF0tA8zb8+b7o0tSm96T-R-SnmOQ@mail.gmail.com>
@ 2022-08-09 10:30   ` Mark Wielaard
  0 siblings, 0 replies; only message in thread
From: Mark Wielaard @ 2022-08-09 10:30 UTC (permalink / raw)
  To: generic-abi; +Cc: elfutils-devel, Di Chen, Milian Wolff

Hi,

CCing the elfutils-devel list where this issue (of missing
DT_SYMTAB_COUNT or DT_SYMTABSZ) does come up occasionally. Which are
needed if you only have the dynamic segment, and not the section
headers, to enumerate all symbols.

On Mon, Aug 08, 2022 at 05:29:19PM -0700, Cary Coutant wrote:
> > We recently had a case where dropping DT_HASH from the generic
> > glibc binaries broke an ELF consumer.
> >
> > For the "real world" details see:
> > https://sourceware.org/pipermail/libc-alpha/2022-August/141302.html
> >
> > I was surprised to see that DT_HASH was "mandatory" in the existing
> > published standard.
> >
> > Why is it mandatory and not optional?
> >
> > Should we and could we make it optional?
> 
> This is an odd situation.
> 
> DT_HASH is mandatory because the "nchain" field in the hash table is
> the only way to know the number of symbols in DT_SYMTAB (unless you
> still have a section table and look for the .dynsym section, which is
> not something we want to require). But when the psABI has effectively
> replaced DT_HASH with something newer, it makes sense for that
> requirement to transfer to the newer table. I suppose the gABI could
> say something like "mandatory unless the psABI provides for a
> replacement in some form," but that doesn't feel right to me. In this
> case, I think it's simply up to the psABI to override the gABI and say
> that DT_HASH is optional if DT_GNU_HASH is present. Unfortunately,
> that means that generic tools that know nothing of ELFOSABI_GNU or
> ELFOSABI_LINUX would be unable to process DT_SYMTAB if they can't find
> DT_HASH.
> 
> I'd probably have preferred to have a mandatory DT_SYMTAB_COUNT or
> DT_SYMTABSZ entry in the dynamic table, which would have enabled us to
> make the hash table (in any form) optional. But the DT_HASH
> requirement has been with us since the beginning of time.

Do you know the reason for not having a DT_SYMTAB_COUNT or
DT_SYMTABSZ? It is not intuitive that one can find the number of
entries through the hash table.

I don't think DT_GNU_HASH can simply be made optional and replace
DT_HASH without adding something like DT_SYMTAB_COUNT or DT_SYMTABSZ
because the gnu hashtable doesn't come with a simple symbol count. To
find the symbol count you have to go through the whole gnu hash table
to count the number of entries (which is a non-trivial amount of
work).

Cheers,

Mark

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-08-09 10:30 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <7864fc03-cd24-2754-a390-a70627af9574@redhat.com>
     [not found] ` <CAJimCsEOsEe8=T8s9sSCw5wF0tA8zb8+b7o0tSm96T-R-SnmOQ@mail.gmail.com>
2022-08-09 10:30   ` Making DT_HASH optional? Mark Wielaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).