public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: generic-abi@googlegroups.com
Cc: elfutils-devel@sourceware.org, Di Chen <dichen@redhat.com>,
	Milian Wolff <mail@milianw.de>
Subject: Re: Making DT_HASH optional?
Date: Tue, 9 Aug 2022 12:30:23 +0200	[thread overview]
Message-ID: <20220809103023.GC553@gnu.wildebeest.org> (raw)
In-Reply-To: <CAJimCsEOsEe8=T8s9sSCw5wF0tA8zb8+b7o0tSm96T-R-SnmOQ@mail.gmail.com>

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

           reply	other threads:[~2022-08-09 10:30 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAJimCsEOsEe8=T8s9sSCw5wF0tA8zb8+b7o0tSm96T-R-SnmOQ@mail.gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220809103023.GC553@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=dichen@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=generic-abi@googlegroups.com \
    --cc=mail@milianw.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).