The ABI status of ELF hash tables

On a more serious note, is there any reason why glibc shouldn't keep DT_HASH around? kilobytes in disk space are hardly a reason to break an application that users are running, even if said application is not one the glibc maintainers like.

> [...] something needs to be done to solve this problem and save gamers from the prospect of having to get some actual work done.

While it may seem silly, there is a large industry of online content creators for whom playing video games is an integral part of work. Besides, we must be wary of glibc maintainers. First they came for Flash Player's use of memcpy, but I did not speak for I was not trying to watch the youtubes. Next, they came for gamers, and I did not speak for I was not a gamer. Once they come for people who spend too much time reading e-mails, there will be no one left to speak for us.

What if the software is not being maintained anymore? Nobody is going to fix it.

Of course this is an ABI break.
Lots of software is not going to be changed, if some random OS developer drops support for some feature.

If glibc doesn't fix this, the only solution for users will be to grab old outdated versions of glibc and throw it into the game bin.

The game should have shipped with all required .so libraries in the first place, though. Including libc.

This line of thinking is completely crazy. Having a replacement available has absolutely nothing to do with whether something is an ABI break or not.

By this reasoning, you could argue that removing memcpy() is not an ABI break because memmove() can do the same thing already and it's been available for ages too.

> Software that is an ELF consumer on Linux has had 16 years to be updated to handle the switch from DT_HASH to DT_GNU_HASH (OS-specific).

and software has had decades to switch from using strcat()/strcpy()/gets() to something more resistant to buffer overflows like strncat()/strncpy()/fgets(), but nobody is talking about removing those APIs from glibc. Why? Because it breaks the ABI!

> Since this process must complete before an application can actually start running, it needs to happen quickly.

I don't think that's generally true; it relies on the executable being linked with `-z now`, otherwise the symbols are resolved lazily (ie. the whole dance with the GOT and PLT). I suspect the implicit default for this flag is configure-able in GNU BFD though, and at this point I suspect most distros would set that as the default. This adds a layer of protection to prevent tampering with the GOT and PLT at runtime.

When symbols are resolved lazily, not "all" symbols references need to be resolved, and the process doesn't need to "complete" before the process starts running.

Using undocumented dependencies that aren't part of the ABI or API is by definition invoking undefined behavior and voiding the warranty.

And microsoft using undocumented APIs to give itself an unfair competitive edge is something they've already been shamed for, and rightly so.

If proprietary games are the ones breaking because they cheated and tried to bypass the warranty provided by the ABI then it serves them right for breaking the rules.

Unfortunately commercial interests will probably spin this to denigrate open source software and unlevel the playing field back in their own favor with proprietary crap that hides dishonest coding practices

No surprise so many Linux products and so much software running on Linux try to avoid glibc. GPLv3 is the legal icing on the cake.

If it's mandated by SysV ABI, it needs to be put back. The fact it's mandated by SysV ABI probably explains why EAC thought they could rely on it being there, even more so than the GNU version. It's not hurting anything to leave it there, so why remove it at all if it's going to break specs and cause anger like this?

Then again, I find some of the developers for projects like glibc just like making inexplicable executive decisions that everyone else who uses their code just has to bend over and take.

And since it's a change to how __libc_start_main behaves in a way that explicitly breaks being run on older linkers (because of course they had to make it feed a NULL where a valid value used to be) you can't just patch around it at compile time either.

Also as noted, the SysV ABI standard requires DT_HASH so they're out of compliance by NOT including it. Supporting not adding it is one thing, but just yeeting it by default definitely is not a good play.

And the global namespace even applies to languages with mangled symbol names.

If the linker preferentially uses DT_GNU_HASH and ignores DT_HASH, and EAC only checks DT_HASH, then create cheats for popular games that include a faked DT_HASH section which pretends everything is OK.

Probably. But DT_HASH has mostly disappeared from Fedora for 16+ years and several other distributions for similarly long years.
libc.so.6 does contain DT_HASH for a long time, but it is just a rare exception.

> The DT_HASH format is mandated by the System V ABI specification, the DT_GNU_HASH format is undocumented, and there has been no deprecation campaign to get users to move on. Chances are those developers are as surprised as anybody and haven't just been ignoring the "switch to DT_GNU_HASH" entry languishing in their issue tracker for the last decade or so. Regardless of blame, though, something needs to be done to solve this problem and save gamers from the prospect of having to get some actual work done.

I think it is fair to say that DT_GNU_HASH is de facto deprecated.
DT_GNU_HASH not in generic ABI is not an issue since In general a processor supplement ABI or an operating system ABI can replace a generic ABI feature, and we should not read too much from the generic ABI wording.

I have more to say on https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash