Should we make DT_HASH dynamic section for glibc?

Adhemerval Zanella Netto
Mon Aug 8 17:31:24 GMT 2022

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


More information about the Libc-alpha mailing list