public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: libc-alpha <libc-alpha@sourceware.org>
Subject: Should we make DT_HASH dynamic section for glibc?
Date: Mon, 8 Aug 2022 14:31:24 -0300	[thread overview]
Message-ID: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> (raw)

It seems that the recent change to remove the multiple hash schemes on 
2.36 [1] broke some specific tools used on proton games [2].  So instead 
of explicit set the section type to use both sysv and gnu, we use the 
toolchain default which might exclude the sysv type.

The last gABI states that DT_HASH is mandatory [3], but DT_GNU_HASH works
a direct replacement meaning that it contains all information for symbol 
resolution that DT_HASH provides.

It was done as size optimization from perceived unused features since
DT_GNU_HASH is being used as a default on most distros for a long time,
meaning DT_HASH might not be set.  For instance, on a Ubuntu 22.05 system
(GLIBC 2.35) only the glibc provided binaries (pldd, gencat, etc.) and some
external tools (nvidia command line) do provide DT_HASH.

So the question is whether we should enforce at least on glibc by reverting
e47de5cb2d4dbec.  It does sounds muddle to keep this solely on glibc, where
rest of the system is not enforcing it, and only for compatibility with an
obscure tools where there is no much information on why it requires it.

Another option might to extend gABI to state that if DT_GNU_HASH is presents,
it works as DT_HASH and it should not mark as mandated.

And if DT_HASH is require required, one possibility is to add a binutils 
option to emit an empty DT_HASH just for compatibility and get the code size
improvement.

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=29456
[3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html

             reply	other threads:[~2022-08-08 17:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 17:31 Adhemerval Zanella Netto [this message]
2022-08-08 20:40 ` Carlos O'Donell
2022-08-08 20:56   ` Carlos O'Donell
2022-08-08 22:59   ` Fangrui Song
2022-08-08 23:36     ` Sam James
2022-08-09  9:21   ` Florian Weimer
2022-09-30 12:56     ` Carlos O'Donell
2022-10-01  7:40       ` Fangrui Song
2022-10-01  8:31         ` Sam James
2022-10-01  8:41           ` Andreas Schwab
2022-10-01 13:49             ` Florian Weimer
2022-10-03 20:57             ` Michael Hudson-Doyle

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=8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /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).