The ABI status of ELF hash tables

Posted Aug 19, 2022 18:25 UTC (Fri) by cgutman (subscriber, #110037)
Parent article: The ABI status of ELF hash tables

> Adhemerval Zanella said: "I am not sure this characterizes as an ABI break since the symbol lookup information would be indeed provided (albeit in a different format)"

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!

The ABI status of ELF hash tables

Posted Oct 26, 2022 18:36 UTC (Wed) by sammythesnake (guest, #17693) [Link]

I don't have any skin in this game, but if I were to try to justify classifying this as "not an ABI change", I think I'd say that the format of the symbol hash is an implementation detail not intended for use outside of the linker.

If the format isn't documented[0] in the documentation for developers using the library, that would be consistent with that position.

It's a weaker guarantee than the one provided by the kernel, though (using the Hyrum's Law[1] model of what constitutes an ABI) but it's a valid position to take if the hash format *is* an implementation detail.

[0] I have very little interest in reading the libc documentation, so maybe it is. The *newer* format is apparently not well documented, though, and the old format predates glibc's use of it, so it being documented for that reason doesn't necessarily torpedo this line of reasoning - it being listed inn the glibc documentation in language other than as an implementation detail would, though...

[1] https://www.hyrumslaw.com/